Bug#890598: RM: dolibarr -- ROM; too much work to maintain it properly in Debian

[Raphaël Hertzog]

Package: ftp.debian.org
Severity: normal

I'm the usual sponsor of dolibarr in Debian. The maintainer (and
upstream author) Eldy Destailleur announced me a few weeks ago that he
will no longer be maintaining Dolibarr within Debian because it was
too much of a pain to respect all the Debian requirements.

He explained to me that Dolibarr relies on 15 javascripts libraries (some of them
are dependencies of the libraries that Dolibarr are using in the first
place) and 5 PHP libraries.

Debian's requirement to provide a non-minified copy of the javascript is
really hard to meet for him because often the projects are only providing
the sources under the form a github link (and not under the form of
a non-minified javascript that we could put next to the minified file to
please lintian). He would have to spend a lot of times with the different
upstreams to get them to provide the non-minified file in a form that is
suitable for Debian. It's even likely that his requests would be dismissed
by multiple upstream authors leaving him in the inconvenient position of
having to remove features to be able to ship a policy-compliant Debian
package.

The requirement to use packaged versions of all the libraries is also
problematic. More often that not the version used by Dolibarr will not
match the version currently available in Debian and it's always a risk
to use a different version. Sometimes it will work just fine, sometimes it
will break.

Given all those constraints, he decided to stop trying to maintain
Dolibarr in Debian and the Dolibarr project will only provide an
unofficial .deb embedding all the libraries that they need.

I doubt anyone else is willing to maintain Dolibarr in Debian and I'm
thus requesting the package to be removed. Users are better served
by the upstream unofficial package rather than by Debian's outdated
package (it's outdated due to the difficulty of updating it in a
policy-compliant way).

I would hope that we could find a way to get the best of both worlds
but right now it seems that we don't have a good solution for that kind
of web application.

Thank you.

[Raphael Hertzog]

Hello everybody,

the fact that I had to request the removal of dolibarr from Debian makes
me sad (see below for the reasons) and I believe that we should be able
to do better to provide complex applications to our end users.

Dolibarr is not alone:

- while gitlab is packaged in Debian, its packaging took years and the
result is brittle because it can break in many ways whenever one the
dozens of dependencies gets updated to some new upstream version
(BTW salsa.debian.org does not use the official package)

- I have the Debian packaging of distro-tracker (the code behind
tracker.debian.org) available in the git repository for years
but I never released it into Debian because it embeds a few javascript
libraries (bootstrap, jquery) and I don't want to validate that
it does work with the versions currently in Debian

I'm sure we are missing lots of good applications due to our requirements.
What can we do to avoid this?

I don't have any definite answers although there are ideas to explore:

- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

- we could ship those applications not as .deb but as container
and let them have their own lifecycle

What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

Cheers,

Post by Raphaël Hertzog
Package: ftp.debian.org
Severity: normal
I'm the usual sponsor of dolibarr in Debian. The maintainer (and
upstream author) Eldy Destailleur announced me a few weeks ago that he
will no longer be maintaining Dolibarr within Debian because it was
too much of a pain to respect all the Debian requirements.
He explained to me that Dolibarr relies on 15 javascripts libraries (some of them
are dependencies of the libraries that Dolibarr are using in the first
place) and 5 PHP libraries.
Debian's requirement to provide a non-minified copy of the javascript is
really hard to meet for him because often the projects are only providing
the sources under the form a github link (and not under the form of
a non-minified javascript that we could put next to the minified file to
please lintian). He would have to spend a lot of times with the different
upstreams to get them to provide the non-minified file in a form that is
suitable for Debian. It's even likely that his requests would be dismissed
by multiple upstream authors leaving him in the inconvenient position of
having to remove features to be able to ship a policy-compliant Debian
package.
The requirement to use packaged versions of all the libraries is also
problematic. More often that not the version used by Dolibarr will not
match the version currently available in Debian and it's always a risk
to use a different version. Sometimes it will work just fine, sometimes it
will break.
Given all those constraints, he decided to stop trying to maintain
Dolibarr in Debian and the Dolibarr project will only provide an
unofficial .deb embedding all the libraries that they need.
I doubt anyone else is willing to maintain Dolibarr in Debian and I'm
thus requesting the package to be removed. Users are better served
by the upstream unofficial package rather than by Debian's outdated
package (it's outdated due to the difficulty of updating it in a
policy-compliant way).
I would hope that we could find a way to get the best of both worlds
but right now it seems that we don't have a good solution for that kind
of web application.
Thank you.

[Roberto C. Sánchez]

Post by Raphael Hertzog
Hello everybody,
the fact that I had to request the removal of dolibarr from Debian makes
me sad (see below for the reasons) and I believe that we should be able
to do better to provide complex applications to our end users.

There was/is a similar issue with ownCloud/nextCloud.

I would love to see something that allows for these complex packages
(package ecosystems, really) to play nice with stock Debian.

I am always hesitant to use unofficial upstream .deb packages unless I
know that they have experienced Debian Developers involved in the
packaging. There have been too many instances for me where such
packages are of poor quality and end up causing more problems than they
solve. My preferred method for applications like this is to install
manually from tarballs and just ignore the unofficial .deb packages.
Sadly, that is nearly always more work.

The container approach is very interesting since many of the most
complex packages would benefit greatly from being kept separate from the
rest of the system for a multitude of reasons. Certainly security is one
and dependency management is another (e.g., as in the Dolibarr example,
where upstream only tests against certain versions of the dependencies
which may not be available directly in Debian).

Anyhow, these are just my thoughts. I would love to see some effort form
around your proposal and would definitely get involved, time permitting.

Regards,

-Roberto

[Samuel Thibault]

Hello,

Post by Raphael Hertzog
it can break in many ways whenever one the
dozens of dependencies gets updated to some new upstream version

To me, that's really the problem: people are writing and piling layers
of free software without really caring about freeness, i.e. being able
to easily access the source code, or to seamlessly use more recent
versions of components. Hell, upstream sometimes tell me that "it's been
one year, i.e. two releases that this feature is deprecated", how can
our world work coherently with such speedy changes?

Post by Raphael Hertzog
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

What kind of relaxation could we introduce without damaging freeness?

The only one I can see is relaxing having to use the version of the
library shipped in Debian.

When I see upstream java packages just stuffing .jar files without
indication of where they come from or even their licencing terms, it's
just unacceptable.

Post by Raphael Hertzog
- we could ship those applications not as .deb but as container
and let them have their own lifecycle

Well, strictly speaking Debian does not actually need to be involved
then, applications are already doing that. But it's indeed a sign that
Debian is losing relevance, which is concerning and Debian could have to
do something about it.

Post by Raphael Hertzog
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

I am annoyed too (I use dolibarr, and am faced with that kind of
dependency hell about some a11y packages). But when I look at the
problem, the real issue is the first one I mentioned above, which not
only is a concern for Debian as you showed, but also for security,
sharing bug fixes etc. and thus the fix should ideally be there, not in
Debian.

Now, we could have separate apt repositories maintained on Debian
servers, so that at least the containers mentioned above would be using
Debian repositories with the corresponding maintenance.

Or we could try to embrace the multiple-library-versions-in-the-same-root
issue like distributions such as NixOS and Guix do. I.e. standardize
alternative places where alternative versions of libraries can be
installed (by installing package whose name contain the major/minor
version so it fits nicely into the dpkg model, and not the release
version so that upgrades are still possible), and the corresponding
environment variables be used to point those complex software at these
dependencies.

Samuel

[Roberto C. Sánchez]

Post by Samuel Thibault
When I see upstream java packages just stuffing .jar files without
indication of where they come from or even their licencing terms, it's
just unacceptable.

I see this as well and am quite frustrated by it. In the university
class I teach, dependency management in our project is something that is
quite important. Though, at that stage of life, the students usually
lack the experience to appreciate why it is important.

Regards,

-Roberto

[W. Martin Borgert]

Post by Samuel Thibault
What kind of relaxation could we introduce without damaging freeness?

And damaging quality. If a program uses some JS libraries without
any sources easily available, I cannot really promote this software.
Neither in Debian nor outside. This is just bad practice.

Post by Samuel Thibault
Or we could try to embrace the multiple-library-versions-in-the-same-root
issue like distributions such as NixOS and Guix do. I.e. standardize
alternative places where alternative versions of libraries can be
installed (by installing package whose name contain the major/minor
version so it fits nicely into the dpkg model, and not the release
version so that upgrades are still possible), and the corresponding
environment variables be used to point those complex software at these
dependencies.

This sounds good, at least for JavaScript libraries and esp. the
Node "ecosystem" (a.k.a. toxic waste dump).

Cheers

[Holger Levsen]

Post by Samuel Thibault
Well, strictly speaking Debian does not actually need to be involved
then, applications are already doing that. But it's indeed a sign that
Debian is losing relevance, which is concerning and Debian could have to
do something about it.

I very much disagree that Debian is loosing relevance, like many software
projects Debian usage is still growing. and other projects grow as well.
Debian was just again voted best linux distro by linux journal. Debian
(and other traditional distros) surely lost relevance in the "web
hosting plattform" "niche" but even there, in numbers we're still
growing. just container based solutions are much more popular today and
they ease installing crap^wstrange bundles.

Post by Samuel Thibault
Or we could try to embrace the multiple-library-versions-in-the-same-root
issue like distributions such as NixOS and Guix do.

you can use their package managers, and thus these features, on Debian
today. there's also docker containers and other options if you want to
use bundled "stuff".

[Samuel Thibault]

Post by Holger Levsen

Post by Samuel Thibault
Or we could try to embrace the multiple-library-versions-in-the-same-root
issue like distributions such as NixOS and Guix do.

you can use their package managers, and thus these features, on Debian
today. there's also docker containers and other options if you want to
use bundled "stuff".

Which is where Debian (and other distributions which care about
freeness, security, etc.) has lost relevance for these use cases. And I
see a lot of growth in the use of this stuff, to the point that I wonder
who will still care about the underlying distributions: will young
developers really care about the ground?

I see more and more READMEs on github telling to just use pip install or
such, the host distribution is basically only used to provide a python
interpreter and/or container host.

Samuel

[W. Martin Borgert]

Post by Holger Levsen
I very much disagree that Debian is loosing relevance, like many software
projects Debian usage is still growing. and other projects grow as well.

I agree.

Post by Holger Levsen
you can use their package managers, and thus these features, on Debian
today. there's also docker containers and other options if you want to
use bundled "stuff".

If I understand Samuels idea correctly, he likes to have multiple
versions of the same (JavaScript) library installed on Debian.
Not "stuff", but proper Debian packages, with all bells and whistles.
Only that you don't remove necessarily the old version, when the new
one comes in. Similar to C libraries, kernel, etc. but with a different
way to actually use the files, of course.

The underlying problem is that:
- We package a JS library. Everything is fine.
- A new version comes. Incompatible? Maybe. Probably.
- If we keep the old version, people complain how outdated we are.
- If we upgrade the package, both packaged software and customer
installed programs break.

This is very much a web application problem. Other software is
less affected in my experience.

Maybe we just have to package JS libraries with their version
number in the package name in the first place?

Cheers

[Samuel Thibault]

Post by W. Martin Borgert
If I understand Samuels idea correctly, he likes to

I don't.

I'm just saying what I'm noticing, not what I like.

Post by W. Martin Borgert
This is very much a web application problem. Other software is
less affected in my experience.

Sure. But the current world is more and more focused on web
applications. If we disconnect from the current world, we'll have a hard
time attracting new people to maintain Debian on the long run.

Post by W. Martin Borgert
Maybe we just have to package JS libraries with their version
number in the package name in the first place?

Provided the files don't conflict, that's what I suggested, yes (much to
my dismay).

Samuel

[Adrian Bunk]

Post by Samuel Thibault
...

Post by W. Martin Borgert
This is very much a web application problem. Other software is
less affected in my experience.

Sure. But the current world is more and more focused on web
applications.

That's not a good justification for doing something if it doesn't fit
into Debian.

Post by Samuel Thibault
If we disconnect from the current world, we'll have a hard
time attracting new people to maintain Debian on the long run.
...

In the current world Debian[1] has an 8 digit userbase on the
Raspberry Pi.

These are existing Debian users, and the Raspberry Pi ecosystem
is culturally much closer to Debian than the JS universe.

If you (or anyone else) wants to spend effort on attracting new people
to maintain Debian, the Raspberry Pi ecosystem would be the more
logical choice here.

Post by Samuel Thibault
Samuel

cu
Adrian

[1] and the Debian derivative Raspbian

[Michael Stone]

While I agree with you, just the number of node-.* (1249) or libjs-.*
(398) packages (which tend to fall within this fast-paced development
culture) makes me shiver... Who will maintain them at different
compatibility levels? Even more so if their upstreams have effectively
abandoned them?

And the real ironic thing is that those packages mainly exist to support
some larger app as dependencies, and that larger app is generally out of
date so people will just install a non-packaged version anyway--at which
point they'll get the node dependencies from live downloads because who
the heck would use debian packages for that instead of using the native
facilities?

Mike Stone

[Gunnar Wolf]

Post by W. Martin Borgert
If I understand Samuels idea correctly, he likes to have multiple
versions of the same (JavaScript) library installed on Debian.
Not "stuff", but proper Debian packages, with all bells and whistles.
Only that you don't remove necessarily the old version, when the new
one comes in. Similar to C libraries, kernel, etc. but with a different
way to actually use the files, of course.
(...)
This is very much a web application problem. Other software is
less affected in my experience.
Maybe we just have to package JS libraries with their version
number in the package name in the first place?

While I agree with you, just the number of node-.* (1249) or libjs-.*
(398) packages (which tend to fall within this fast-paced development
culture) makes me shiver... Who will maintain them at different
compatibility levels? Even more so if their upstreams have effectively
abandoned them?

[Vincent Bernat]

Post by Holger Levsen

Post by Samuel Thibault
Well, strictly speaking Debian does not actually need to be involved
then, applications are already doing that. But it's indeed a sign that
Debian is losing relevance, which is concerning and Debian could have to
do something about it.

I very much disagree that Debian is loosing relevance, like many software
projects Debian usage is still growing. and other projects grow as well.
Debian was just again voted best linux distro by linux journal. Debian
(and other traditional distros) surely lost relevance in the "web
hosting plattform" "niche" but even there, in numbers we're still
growing. just container based solutions are much more popular today and
they ease installing crap^wstrange bundles.

I don't know where you got figures to support this case, but I have the
inverse feeling (and no figures either). Arch is taking away our desktop
users, Ubuntu is taking away our cloud users, Alpine is taking away our
container users and CoreOS/Atomic Host are taking away users interested
by container orchestration solutions.

Post by Holger Levsen

Post by Samuel Thibault
Or we could try to embrace the multiple-library-versions-in-the-same-root
issue like distributions such as NixOS and Guix do.

you can use their package managers, and thus these features, on Debian
today. there's also docker containers and other options if you want to
use bundled "stuff".

With the small drawback that Docker is only in Sid (and outdated).

[Michael Meskes]

Post by Vincent Bernat
I don't know where you got figures to support this case, but I have the
inverse feeling (and no figures either). Arch is taking away our desktop
users, Ubuntu is taking away our cloud users, Alpine is taking away our
container users and CoreOS/Atomic Host are taking away users
interested
by container orchestration solutions.

Not sure about those details, but yes, this is my gut feeling, too.

Michael

[Adrien CLERC]

Post by Raphael Hertzog
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

Yes, indeed. I am more a simple user of Debian than a real Debian
Developer, but my feeling is paradoxical.
On one hand, I'd love to see some complex application in Debian, or at
least most of its dependencies.
On the other hand, I can only be angry against people than only release
minified source. The usual answer to this is "performance" or "everyone
does this". The debate has been opened for a long time, but a
minification operation is somewhat like a compilation: it is hard to get
the human readable form from it.
So I'd vote "no" to relax, even if some application are taken out.

As an example, there is this grafana issue on

Post by Raphael Hertzog
 torkelo commented on 15 May 2016
Github source tar has never been 100% comprehensive, Grafana has
always required "npm install" to build (like most web apps)

This is incredibly dangerous since the build rely on NPM repository
which is far from trusty. And it relies on minified files everywhere,
that break the social contract. I installed Grafana on my Debian/testing
when the package was available, because then I knew it could be trusted.
Now, it is more appealing than before (Grafana is a good software), but
trust has gone away.

It is true that software are harder to review nowadays, because they
rely on lots of libraries. But there is a real difference to me between
"hard" and "impossible".

For the JavaScript world, a solution would require a well-known standard
about minification and optimization. The WebAssembly is coming, and this
will worst.

[Michael Meskes]

Post by Raphael Hertzog
What can we do to avoid this?
I don't have any definite answers although there are ideas to
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)
- we could ship those applications not as .deb but as container
and let them have their own lifecycle
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

Can't we treat a .deb file like a container in the sense that it may
include additional source if needed? I'd very much like this.

I know that this does create some problems for us, e.g. on the security
side, but the alternative is, as you mentioned, manually installed
software and that surely is worse.

Maybe we should restrict this approach to areas where this problem is
very common, like javascript? At least initially.

Michael

[Michael Stone]

Post by Michael Meskes
I know that this does create some problems for us, e.g. on the security
side, but the alternative is, as you mentioned, manually installed
software and that surely is worse.

No, I think it's better if people know they're on their own for
maintaining something. What's surely worse is when we ship stuff that we
know we can't properly maintain in the long term. Better to be out of
the archive than in without the expected level of quality.

Mike Stone

[Michael Meskes]

Post by Michael Meskes
I know that this does create some problems for us, e.g. on the security
side, but the alternative is, as you mentioned, manually installed
software and that surely is worse.

No, I think it's better if people know they're on their own for maintaining
something. What's surely worse is when we ship stuff that we know we can't
properly maintain in the long term. Better to be out of the archive than in
without the expected level of quality.

Who said we cannot properly maintain this stuff? And where do you think our expected level of quality (whatever that is) will not be reached?

Michael

[Sean Whitton]

Hello Michael,

Post by Michael Meskes
Who said we cannot properly maintain this stuff? And where do you
think our expected level of quality (whatever that is) will not be
reached?

We cannot feasibly provide security updates when there is more than one
version of the library in the archive. We do not, and probably never
will have, the required manpower.

This applies to the nixos/guix solutions too -- we cannot expect our
security team to go around backporting patches to all the different
versions we're offering to users.

[W. Martin Borgert]

Post by Sean Whitton
We cannot feasibly provide security updates when there is more than one
version of the library in the archive. We do not, and probably never
will have, the required manpower.
This applies to the nixos/guix solutions too -- we cannot expect our
security team to go around backporting patches to all the different
versions we're offering to users.

This is true. We would have to be clear, that security support
would have to be limited to one (the latest?) version. This is
still a difference to some arbitrary compressed js files with no
source code, no copyright information etc. which people use when
there is no Debian package at all.

But it's probably too much work, preparing infrastructure etc.

Anyway, relaxing requirements on source code availability,
building from sources with tools within Debian, free license,
etc. is not an option for me. Not only in the context of Debian.

[Michael Meskes]

Post by W. Martin Borgert
This is true. We would have to be clear, that security support
would have to be limited to one (the latest?) version. This is
still a difference to some arbitrary compressed js files with no
source code, no copyright information etc. which people use when
there is no Debian package at all.
But it's probably too much work, preparing infrastructure etc.

Why?

Post by W. Martin Borgert
Anyway, relaxing requirements on source code availability,
building from sources with tools within Debian, free license,
etc. is not an option for me. Not only in the context of Debian.

I've been doing Debian for so long now but I still cannot grasp the way
discussions are going. How on earth did we get from the technical problem of
how to package large application stacks that come with their own copies of
certain "libraries" to packaging software that is neither free nor open source?
I didn't notice anyone suggesting we should do the latter.

Michael

[W. Martin Borgert]

Post by Michael Meskes

Post by W. Martin Borgert
But it's probably too much work, preparing infrastructure etc.

Why?

Depends how it would be done. Nixos style would probably very
difficult for Debian. Packages with version number in their
name would be no packaging problem at all, but we would have
to make clear, that security support is not likely.

Post by Michael Meskes

Post by W. Martin Borgert
Anyway, relaxing requirements on source code availability,
building from sources with tools within Debian, free license,
etc. is not an option for me. Not only in the context of Debian.

I've been doing Debian for so long now but I still cannot grasp the way
discussions are going. How on earth did we get from the technical problem of
how to package large application stacks that come with their own copies of
certain "libraries" to packaging software that is neither free nor open source?
I didn't notice anyone suggesting we should do the latter.

Is was a relevant part of the problem mentioned in Raphaels bug
report: Minified JS libraries without source code. this was one
of the starting points of this discussion. (#890598)

The bug report mentions two orthogonal problems:
- libraries without source code or no license information
- libraries which are needed in specific versions
I add a third one:
- libraries that are not packaged, because there are too many

Cheers

[Michael Meskes]

Post by W. Martin Borgert
Depends how it would be done. Nixos style would probably very
difficult for Debian. Packages with version number in their
name would be no packaging problem at all, but we would have
to make clear, that security support is not likely.

Sure, I don't see a problem with this.

Post by W. Martin Borgert

Post by Michael Meskes
discussions are going. How on earth did we get from the technical problem of
how to package large application stacks that come with their own copies of
certain "libraries" to packaging software that is neither free nor open source?
I didn't notice anyone suggesting we should do the latter.

Is was a relevant part of the problem mentioned in Raphaels bug
report: Minified JS libraries without source code. this was one
of the starting points of this discussion. (#890598)

Right, although merely technical since there is source code, albeit not
very legible or maintainable.

Post by W. Martin Borgert
- libraries without source code or no license information

I might have missed the missing license problem, but I'm pretty noone
wants to see unlicensed software in Debian, which also would be
illegal.

Post by W. Martin Borgert
- libraries which are needed in specific versions

This one really worries me. I wonder how many similar cases we already
have, where somebody took some code and changed it slightly before
including it.

Post by W. Martin Borgert
- libraries that are not packaged, because there are too many

The problem is probably less the amount but more the manual work to
find the canonical sources. Packing a go "library" for instance does
not take a lot of time, because it can be done mostly automated.

Michael

[Gunnar Wolf]

Post by Michael Meskes

Post by W. Martin Borgert
Is was a relevant part of the problem mentioned in Raphaels bug
report: Minified JS libraries without source code. this was one
of the starting points of this discussion. (#890598)

Right, although merely technical since there is source code, albeit not
very legible or maintainable.

Minification is quite comparable to compilation. I will give you some
examples from my frustration with Drupal8 in this answer. This can no
longer be seen as source code:

https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/core/assets/vendor/classList/classList.min.js

And it's far from the ugliest example I can quote. Of course, I needed
to ship sources for all of them - Take a look at:

https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/debian/missing-sources/README

And, of course, think about the huge diff that is to be created for
all of the files in debian/missing-sources.

Post by Michael Meskes

Post by W. Martin Borgert
- libraries without source code or no license information

I might have missed the missing license problem, but I'm pretty noone
wants to see unlicensed software in Debian, which also would be
illegal.

Take this as an example of what is needed for a moderately complex PHP
webapp with lots of JS in it:

https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/debian/copyright

Of course, it was all hand-generated and validated.

Post by Michael Meskes

Post by W. Martin Borgert
- libraries which are needed in specific versions

This one really worries me. I wonder how many similar cases we already
have, where somebody took some code and changed it slightly before
including it.

And that's where I dropped the ball. Upstream says they will keep
dependencies refreshed - that means that every project version bump,
they will pull in the newest stable versions for all of the projects I
covered in the above links. Of course, I had come up with a clunky bit
in my debian/rules to track any changes:

override_dh_install:
# Ensure the list of third-party included libraries remains
# consistent with what we already checked
SHATMP=`mktemp --tmpdir SHA_CK.XXXXX` && \
sha256sum core/core.libraries.yml > $$SHATMP && \
diff -q debian/missing-sources/tracking.sha256 $$SHATMP && \
rm $$SHATMP

But... That would inescapably be run at every minor bump. And it's
just too much of a PITA to build.

Post by Michael Meskes

Post by W. Martin Borgert
- libraries that are not packaged, because there are too many

The problem is probably less the amount but more the manual work to
find the canonical sources. Packing a go "library" for instance does
not take a lot of time, because it can be done mostly automated.

But packaging the precise version that is required in each little bump
is just impossible.

[Michael Meskes]

Post by Gunnar Wolf
Minification is quite comparable to compilation. I will give you some
examples from my frustration with Drupal8 in this answer. This can no
...

I disagree, it is not maintainable source code, yes, but source code
nonetheless. According to wikipedia source code is:

In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.

I guess minified source code does qualify. However, this discussion is
mood since the bigger lies in the modules that get included without any
real documentation.

Post by Gunnar Wolf
And it's far from the ugliest example I can quote. Of course, I needed
https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/deb
ian/missing-sources/README
And, of course, think about the huge diff that is to be created for
all of the files in debian/missing-sources.

Agreed this is ugly and I'm all in if we can find a better solution.
but just not having all these applications does not strike me as a
better solution.

Post by Gunnar Wolf
Take this as an example of what is needed for a moderately complex PHP
https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/deb
ian/copyright
Of course, it was all hand-generated and validated.

And your point being?

Post by Gunnar Wolf
But packaging the precise version that is required in each little bump
is just impossible.

I get your point, I just don't accept the consequence that we should
not package these applications.

Michael

[Samuel Thibault]

Post by Michael Meskes

Post by Gunnar Wolf
Minification is quite comparable to compilation. I will give you some
examples from my frustration with Drupal8 in this answer. This can no
...

I disagree, it is not maintainable source code, yes, but source code
In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.

And according to the GPL, it is

“
The source code for a work means the preferred form of the work for
making modifications to it.
”

minified source is definitly not that.

That's not something one can maintain anyway, so really not source code.

You could as well claim that you can modify binary ELF files: for the
processor, it's source code.

Samuel

[Philip Hands]

Post by Michael Meskes

Post by Gunnar Wolf
Minification is quite comparable to compilation. I will give you some
examples from my frustration with Drupal8 in this answer. This can no
...

I disagree, it is not maintainable source code, yes, but source code
nonetheless.

The settled opinion of the FTP team (and the TC for that matter) is:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#235

that for our purposes it is not source code.

Cheers, Phil.

[Paul Wise]

Post by Michael Meskes
I disagree, it is not maintainable source code, yes, but source code
In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.
I guess minified source code does qualify. However, this discussion is
mood since the bigger lies in the modules that get included without any
real documentation.

It may be code but it is definitely not source in the sense of DFSG
item 2 or the GPL.

[Paul Wise]

Post by Paul Wise
It may be code but it is definitely not source in the sense of DFSG
item 2 or the GPL.

Also, non-minified JavaScript can also not be source code, for example
in the case it was generated from CoffeeScript or some other language.

[W. Martin Borgert]

Post by Michael Meskes
I disagree, it is not maintainable source code, yes, but source code
In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.

I disagree with the wikipedia definition. The "source" (Quelle,
fuente) is the "origin" that is the form of code that is not
only readable but also writable. In general any generated file,
even if readable and in text form, is not source code.

[Sergio Durigan Junior]

Post by Michael Meskes

Post by Gunnar Wolf
Minification is quite comparable to compilation. I will give you some
examples from my frustration with Drupal8 in this answer. This can no
...

I disagree, it is not maintainable source code, yes, but source code
In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.
I guess minified source code does qualify. However, this discussion is
mood since the bigger lies in the modules that get included without any
real documentation.

You can disagree, but you still can't edit and maintain the minified JS.
This is basically what is expected from a source code (and it doesn't
really matter whether Wikipedia's definition is different). If you've
had to deal with minified JS, then you know it's the same as dealing
with binary code.

[Adam Borowski]

Post by Sergio Durigan Junior

Post by Michael Meskes
I disagree, it is not maintainable source code, yes, but source code
In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.

You can disagree, but you still can't edit and maintain the minified JS.
This is basically what is expected from a source code (and it doesn't
really matter whether Wikipedia's definition is different). If you've
had to deal with minified JS, then you know it's the same as dealing
with binary code.

Binary code that has debug symbols isn't that bad. I don't think you can
have those for minified JS.

(I can read adequately only x86 assembly, but reading other archs isn't
a rare skill.)

[Colin Watson]

Post by Adam Borowski
Binary code that has debug symbols isn't that bad. I don't think you can
have those for minified JS.

JavaScript source maps have been around for a few years and AIUI are
pretty much exactly that.

[Gunnar Wolf]

Post by Michael Meskes

Post by Gunnar Wolf
Minification is quite comparable to compilation. I will give you some
examples from my frustration with Drupal8 in this answer. This can no
...

I disagree, it is not maintainable source code, yes, but source code
In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.
I guess minified source code does qualify. However, this discussion is
mood since the bigger lies in the modules that get included without any
real documentation.

Some others have answered to this claim. As I understand it, source
code should ideally be the author's preferred form of
modification. That is clearly different from what a minified
representation is.

Even adjusting this a bit... Maybe not a preferred form of
modification, but a plausible form for performing support? Well, even
leaving the obvious change from a readable, indented set of
instructions to a single line with no comments nor anything to aid
humans to understand it, it also does not cut the bill. Minification
preserves function (and thus, calls to the stdlib and such are
discernible), but function and variable names are mangled. That is a
_huge_ obstacle for being able to fix anything but the most trivial
details. Of course, we cannot push our patches upstream.

Post by Michael Meskes

Post by Gunnar Wolf
But packaging the precise version that is required in each little bump
is just impossible.

I get your point, I just don't accept the consequence that we should
not package these applications.

Well, try to find somebody with time and motivation to _properly_ do
the packaging, and to keep it up for several years...

[Michael Meskes]

Post by Gunnar Wolf

Post by Michael Meskes
I disagree, it is not maintainable source code, yes, but source code
...

Some others have answered to this claim. As I understand it, source
code should ideally be the author's preferred form of
modification. That is clearly different from what a minified
representation is.
...

It's amazing how my email seems to have been understood differs from
what I wanted to say. I thought it was clear from the "not
maintainable" part that I did not suggest we use minified source as
source code. I was merely pointing out that it technically still was
source code in the sense that the same compiler/interpreter yields the
same result with the minified code as with the original one.

For all practical manners this is irrelevant.

Post by Gunnar Wolf

Post by Michael Meskes
I get your point, I just don't accept the consequence that we should
not package these applications.

Well, try to find somebody with time and motivation to _properly_ do
the packaging, and to keep it up for several years...

I absolutely agree with you that it does not work with our current way
of packaging, but that's what this discussion about. IMO it would be
great if we found a way to offer these applications to our users.

Michael

[Raphael Hertzog]

Post by W. Martin Borgert
Is was a relevant part of the problem mentioned in Raphaels bug
report: Minified JS libraries without source code. this was one
of the starting points of this discussion. (#890598)

It's not "without source code", it's just that the source code of a single
.min.js is not another non-minified javascript file but a whole git
repository that you can't just drop near the .min.js file to please lintian.

And building ourselves the non-minified file together with the corresponding
minified file is just too time-consuming on the long term when you rely on
dozens of libraries.

Cheers,

[Michael Stone]

Post by W. Martin Borgert
This is true. We would have to be clear, that security support
would have to be limited to one (the latest?) version. This is
still a difference to some arbitrary compressed js files with no
source code, no copyright information etc. which people use when
there is no Debian package at all.

That's exactly what I was objecting to--the end user will then install
the package from debian in good faith and have no idea whether it's on
the "not really supported" list. I'd much rather have them install it
from a third party (most of which nowadays have some sort of update
mechanism).

Mike Stone

[Michael Meskes]

Post by Sean Whitton
We cannot feasibly provide security updates when there is more than one
version of the library in the archive. We do not, and probably never
will have, the required manpower.
This applies to the nixos/guix solutions too -- we cannot expect our
security team to go around backporting patches to all the different
versions we're offering to users.

Yeah, I was expecting this point and I don't agree. Well, I do agree on it's
being too much of a burden for us to backport all fixes to each version, but I
do not agree on that being what we need to do.

If we were to package applications as containers (not necessarily
docker-style!) we could and should have different rules for those. Just see
what people will do otherwise, use a Linux distribution and install manually
and then, maybe, update when a fixed version of the application comes out. IMO
we should do exactly the same and make sure the application containers get
update to fixed version as and when possible. For users this means that get
probably better security and easier deployment of whatever application they
need to run. Obviously this needs to be clearly documented.

Michael

[Sean Whitton]

Hello Michael,

Post by Michael Meskes

Post by Sean Whitton
We cannot feasibly provide security updates when there is more than
one version of the library in the archive. We do not, and probably
never will have, the required manpower.
This applies to the nixos/guix solutions too -- we cannot expect our
security team to go around backporting patches to all the different
versions we're offering to users.

Yeah, I was expecting this point and I don't agree. Well, I do agree
on it's being too much of a burden for us to backport all fixes to
each version, but I do not agree on that being what we need to do.
If we were to package applications as containers (not necessarily
docker-style!) we could and should have different rules for
those. Just see what people will do otherwise, use a Linux
distribution and install manually and then, maybe, update when a fixed
version of the application comes out. IMO we should do exactly the
same and make sure the application containers get update to fixed
version as and when possible. For users this means that get probably
better security and easier deployment of whatever application they
need to run. Obviously this needs to be clearly documented.

Yes, I think that Debian should eventually be providing a repository of
flatpaks (or similar) alongside our apt repos.

One of smcv's talk at DebConf17 explains the advantages of doing this:
https://debconf17.debconf.org/talks/59/

[Paul Wise]

Post by Sean Whitton

Post by Michael Meskes
If we were to package applications as containers (not necessarily
docker-style!) we could and should have different rules for
those....

Yes, I think that Debian should eventually be providing a repository of
flatpaks (or similar) alongside our apt repos.

I think the discussion we are having here is orthogonal to containers/flatpaks.

If Debian were to have a repository of containers/flatpaks, then it
should meet Debian standards. We cannot just say "here are some
containers, completely unsupported and might not up to our standards".
To achieve that, I think it would be best to automatically convert it
from Debian binary packages. Also, since we are already doing
packaging work, it makes sense to base any container efforts on that,
just like our cloud efforts have been.

There is flathub, dockerhub etc for containers/flatpaks that may or
may not meet Debian standards.

Post by Sean Whitton
https://debconf17.debconf.org/talks/59/

IIRC, many applications have to be rebuilt for this particular
incarnation of converting Debian to flatpaks (except programs that are
already relocatable). Personally I am not sure we need additional
burden on the buildds.

[Russ Allbery]

Post by Paul Wise
I think the discussion we are having here is orthogonal to
containers/flatpaks.
If Debian were to have a repository of containers/flatpaks, then it
should meet Debian standards. We cannot just say "here are some
containers, completely unsupported and might not up to our standards".
To achieve that, I think it would be best to automatically convert it
from Debian binary packages. Also, since we are already doing packaging
work, it makes sense to base any container efforts on that, just like
our cloud efforts have been.

I agree with this.

Putting aside completely missing licenses or completely missing source
code (these are sometimes more fixable problems, since those are
considered suspect practices even in the upstream communities), the root
problem here is vendored dependencies. Most modern languages, not just
Java and Node, are switching to vendored dependencies with some mechanism
for freezing the dependencies for a project. See Rust, Go, and
increasingly, Python and Ruby, and I would expect to see the same for any
new, popular programming language.

For better or worse, there's a general consensus upstream of us in a lot
of language communities that API backward compatibility and continuous
upgrades are simply too hard, and breaking changes (ideally with semver)
plus freezing and vendoring dependencies are the best solution. We can
certainly disagree with this, but this approach has a ton of momentum
behind it, and we're swimming upstream right now. We convince some folks,
but not many, and the Node ecosystem in particular is so firmly committed
to this approach that it's hard to imagine them backing away from it.

So, where does that leave us?

The reason why Debian in general doesn't like to support vendored source
is because of the security implications: when there's a security
vulnerability in one of the vendored libraries, updating the relevant
packages becomes a nightmare. It's a logistical challenge even if the
vendored source can be safely upgraded, but of course it usually can't
since that's the whole point of vendoring the source. So we would be
faced with backporting security fixes to every vendored version of the
package, and we don't have the resources to do this.

Note that this is not a *Debian* problem, this is an *ecosystem* problem.
No one *else* has the resources to do this either, and generally what
happens out there in the world is that this is just not done. Those
applications blithely continue running with vulnerable versions of their
dependencies, and aren't updated.

I think it's important to note here that we're not wrong. Our approach is
substantially more secure because we can patch software. Vendoring
everything is substantially less secure since you're relying on the
application developer to re-vendor fixed versions, and they may not even
know there was a vulnerability. (High-quality vulnerability feeds for a
lot of these ecosystems are very hard to come by.) It's not that someone
else is succeeding where we're failing; it's that lots of other people
have decided to just blow off security in the name of convenience and hope
they don't get bitten by this.

Using flatpak therefore doesn't really change the equation. It *does*
provide some jailing by default, which can protect some against a certain
type of vulnerabilities (and which we could provide in other ways as well;
flatpak just makes it easier). But it does nothing against the more
common problems of, say, XSS vulnerabilities in some Javascript library
used for the web front end of the application.

It's hard to avoid the feeling that we have two choices with these sorts
of applications:

1. Lower our security standards and provide whatever the application
developer provides, relying on them to re-vendor for security updates.
This would probably mean not releasing these packages with stable
releases or immediately adding them to the unsupported security list,
unless we're going to significantly relax the normal security
guarantees we provide.

2. Maintain our security standards, reject packages with large amounts of
vendored software, and therefore, in practice, ask our users to
separately install such software via whatever means the application
developer provides. Users who choose to do this won't be any more
secure (they'll probably be somewhat less secure since those updates
won't be hooked into their normal system update process), but at least
they have to make a conscious choice to opt in to that behavior, and a
Debian installation with pure Debian packages is relatively secure by
default.

So far, we've defaulted in option 2, which means we're not packaging a lot
of very useful software. But I don't think this is due to some obvious
error on our part. The only practical alternative appears to be 1, and 1
is really not very appealing. It does make things more convenient for our
users, but at a substantial cost to our security guarantees.

I suppose a possible third option would be a new archive that explicitly
has no security support, sort of similar conceptually to how we handle
non-free or contrib. That would be a sort of compromise, but I'm not sure
it would make anyone happy.

[Tollef Fog Heen]

]] Russ Allbery

Post by Russ Allbery

Post by Paul Wise
I think the discussion we are having here is orthogonal to
containers/flatpaks.
If Debian were to have a repository of containers/flatpaks, then it
should meet Debian standards. We cannot just say "here are some
containers, completely unsupported and might not up to our standards".
To achieve that, I think it would be best to automatically convert it
from Debian binary packages. Also, since we are already doing packaging
work, it makes sense to base any container efforts on that, just like
our cloud efforts have been.

I agree with this.
Putting aside completely missing licenses or completely missing source
code (these are sometimes more fixable problems, since those are
considered suspect practices even in the upstream communities), the root
problem here is vendored dependencies. Most modern languages, not just
Java and Node, are switching to vendored dependencies with some mechanism
for freezing the dependencies for a project. See Rust, Go, and
increasingly, Python and Ruby, and I would expect to see the same for any
new, popular programming language.

I think there's at least two types of vendoring you're referring to
here, and they're substantially different.

One is how Go currently does (but my understanding is that this is
changing in newer versions). Here, the source code of dependencies are
shipped together with the source code for the application. This leads
to trees like
https://github.com/kubernetes/kubernetes/tree/master/vendor where any
one of those dependencies might be a released version or tag, or it
might just be a random git snapshot, and there's not really any way to
know.

The other (you refer to this as freezing dependencies) is how
Node.js/npm/yarn, Ruby/gem, (to some extent) Python/pip, and Rust/cargo
does it. In those cases, you have some file specifying the versions of
libraries the application needs, usually as «this version of this
gem/crate/package» and there is somewhere those packages live by
default. Quite often, there's also a lock file of some sort which lists
out the exact versions used, recursively, which ensures you can deploy
the exact same code multiple times.

The second method means you can reason about what versions of code are
included where. You might still have to patch five versions of
libvulnerable, but at least it's possible to find which five versions
are in use, and get those fixed in a central place and then rebuild
everything that's vulnerable, recursively. Not the most fun job in the
world, but it's at least possible to automate somewhat.

I'm curious what, if anything, we can do to better support the second
model. In particular because (as you note) it's very much in vogue with
lots of upstreams those days.

[Colin Watson]

Post by Tollef Fog Heen
I think there's at least two types of vendoring you're referring to
here, and they're substantially different.
One is how Go currently does (but my understanding is that this is
changing in newer versions). Here, the source code of dependencies are
shipped together with the source code for the application. This leads
to trees like
https://github.com/kubernetes/kubernetes/tree/master/vendor where any
one of those dependencies might be a released version or tag, or it
might just be a random git snapshot, and there's not really any way to
know.
The other (you refer to this as freezing dependencies) is how
Node.js/npm/yarn, Ruby/gem, (to some extent) Python/pip, and Rust/cargo
does it. In those cases, you have some file specifying the versions of
libraries the application needs, usually as «this version of this
gem/crate/package» and there is somewhere those packages live by
default. Quite often, there's also a lock file of some sort which lists
out the exact versions used, recursively, which ensures you can deploy
the exact same code multiple times.
The second method means you can reason about what versions of code are
included where.

This is an excellent point. (In fact, I think you can do some of that
reasoning for the first method too; it's just going to take more effort.
For example, you could run "govendor sync" or whatever and check that
the output tree actually matches what's promised. In some ways this is
similar to the question of "is this package's .orig.tar actually the
version it claims to be?".)

It's worth remembering that this isn't just some lazy upstreams not
getting round to keeping their dependencies up to date:

* Often they need newer versions of dependencies than are in Debian
stable, because retaining compatibility back to whatever version we
shipped for a half-million-line web application and actually testing
the result is a combinatorially-hard problem.

* Often the existence of packaged web applications in Debian itself
makes it harder to upgrade the libraries they depend on. Take
Django, for instance: it has really remarkably good documentation of
what you need to do to upgrade an application to a newer version and
a very clear deprecation policy, but you still have to do it and
keeping your application compatible with more than two or three
Django versions (by which I mean 1.8, 1.9, 1.10, etc.) before the
newest one you support is likely to be pretty painful. Now package
half a dozen Django applications and suddenly the library package
maintainers have a heck of a time keeping everything working. [1]

* And yes, sometimes an upstream can end up with out-of-date
dependencies that are going to take significant effort to resolve,
but there's something to be said for making it possible to shift the
upgrade effort to a time when it's convenient to do so, even though
there's obviously a trade-off with the possibility that you might end
up putting it off indefinitely. Not to mention that if they did
upgrade their dependencies, they might end up being incompatible with
the versions in Debian stable, and as it is that doesn't help our
users of packaged applications very much either. The lockstep
problem is really nasty.

* Packaging individual libraries that aren't especially useful on the
client side can be pretty boring work and is often not very socially
valued (the people trying to deal with JavaScript dependencies in
Debian have taken a lot of flak, for instance).

And yet ... it can be really nice to have some of these things packaged
in a common format. I know roughly nothing about PHP, and I don't want
to have to learn yet another packaging stack or another upstream's
favourite container technology, so it's great that Icinga Web 2 is
packaged so that I can just install it without having to learn that. I
want it to be as easy as possible for the security team and the people
who care about it to keep it up to date. For the case where something
depends on OpenSSL, it's mostly pretty obvious where the trade-offs lie.
For the case where something depends on 80 npm libraries and a security
update to the application might require updating 10 of those and maybe
breaking some other packaged application in the process, it's not so
clear that it even serves our developers let alone our users.

[1] Disclaimer: I only do in-house development at work of Django
applications that aren't packaged in Debian, and I'm not involved in
Django's Debian maintenance, so this is an outside view and I may
have some details wrong.

Post by Tollef Fog Heen
You might still have to patch five versions of libvulnerable, but at
least it's possible to find which five versions are in use, and get
those fixed in a central place and then rebuild everything that's
vulnerable, recursively. Not the most fun job in the world, but it's
at least possible to automate somewhat.

So maybe what we need is to run with that a bit further? Debian has
historically been really good at coming up with ways to represent what
disparate upstream developers are doing in formats that can be consumed
in single common ways, so e.g. you can upgrade your system with a single
command rather than having to go and work out what to do for each
package. We could probably come up with a common format representing a
package's frozen dependencies, in the spirit of Built-Using, and see if
it's possible to build reasonable security workflows around those. For
instance, as a strawman starting point, we could aim for rules like
these:

* Constrained to the sort of server-side applications that might
reasonably be run in a container on their own, just to keep the
problem size down a bit.

* No freezing of stuff that's outside of the primary language ecosystem
involved (so your Python webapp doesn't get to come up with a fancy
way to vendor OpenSSL).

* Maybe truncate the frozen dependency tree at C extensions, in order
that we can make sure those are built for all architectures, so you'd
still have to care about compatibility with those. It'd be a much
smaller problem, though.

* Every frozen dependency must be installed in a particular defined
path based on (application name, dependency name, dependency
version), and must be installed using blessed tools that generate
appropriate packaging metadata that can be scanned centrally without
having to download lots of source packages.

* Updating a single frozen dependency (assuming no API changes to the
application's source code) must be no harder than updating a single
line in a single file and bumping the Debian package version.

* Where applicable, deprecation warnings must be configured as
warnings, not errors, to maximise compatibility.

* Dependencies with a non-trivial CVE history would have an acceptable
range of versions, so we could drop applications that persistently
cause trouble while still allowing a bit of slack. For some
dependencies it might not be a problem at all; e.g. we probably don't
care what version of python-testtools something uses.

* We put all this together in a separate archive that explicitly
doesn't have security support; the security team wouldn't be expected
to provide support until the tooling is in a state where it's easy
enough for them.

I dunno. Maybe this is all so much blowing smoke, since I'm not
actually volunteering ... but I develop webapps in the
frozen-dependencies style at work and still see value that a
distribution like Debian could provide by way of packaging, so wanted to
offer some suggestions that I think might be useful compromises.

[David Zhan]

  原始訊息  
寄件者： Colin Watson
已傳送： Sonntag, 18. Februar 2018 10:15
收件者： debian-***@lists.debian.org
主旨： Re: What can Debian do to provide complex applications to its users?

Post by Tollef Fog Heen
I think there's at least two types of vendoring you're referring to
here, and they're substantially different.
One is how Go currently does (but my understanding is that this is
changing in newer versions). Here, the source code of dependencies are
shipped together with the source code for the application. This leads
to trees like
https://github.com/kubernetes/kubernetes/tree/master/vendor where any
one of those dependencies might be a released version or tag, or it
might just be a random git snapshot, and there's not really any way to
know.
The other (you refer to this as freezing dependencies) is how
Node.js/npm/yarn, Ruby/gem, (to some extent) Python/pip, and Rust/cargo
does it. In those cases, you have some file specifying the versions of
libraries the application needs, usually as «this version of this
gem/crate/package» and there is somewhere those packages live by
default. Quite often, there's also a lock file of some sort which lists
out the exact versions used, recursively, which ensures you can deploy
the exact same code multiple times.
The second method means you can reason about what versions of code are
included where.

This is an excellent point. (In fact, I think you can do some of that
reasoning for the first method too; it's just going to take more effort.
For example, you could run "govendor sync" or whatever and check that
the output tree actually matches what's promised. In some ways this is
similar to the question of "is this package's .orig.tar actually the
version it claims to be?".)

It's worth remembering that this isn't just some lazy upstreams not
getting round to keeping their dependencies up to date:

* Often they need newer versions of dependencies than are in Debian
stable, because retaining compatibility back to whatever version we
shipped for a half-million-line web application and actually testing
the result is a combinatorially-hard problem.

* Often the existence of packaged web applications in Debian itself
makes it harder to upgrade the libraries they depend on. Take
Django, for instance: it has really remarkably good documentation of
what you need to do to upgrade an application to a newer version and
a very clear deprecation policy, but you still have to do it and
keeping your application compatible with more than two or three
Django versions (by which I mean 1.8, 1.9, 1.10, etc.) before the
newest one you support is likely to be pretty painful. Now package
half a dozen Django applications and suddenly the library package
maintainers have a heck of a time keeping everything working. [1]

* And yes, sometimes an upstream can end up with out-of-date
dependencies that are going to take significant effort to resolve,
but there's something to be said for making it possible to shift the
upgrade effort to a time when it's convenient to do so, even though
there's obviously a trade-off with the possibility that you might end
up putting it off indefinitely. Not to mention that if they did
upgrade their dependencies, they might end up being incompatible with
the versions in Debian stable, and as it is that doesn't help our
users of packaged applications very much either. The lockstep
problem is really nasty.

* Packaging individual libraries that aren't especially useful on the
client side can be pretty boring work and is often not very socially
valued (the people trying to deal with JavaScript dependencies in
Debian have taken a lot of flak, for instance).

And yet ... it can be really nice to have some of these things packaged
in a common format. I know roughly nothing about PHP, and I don't want
to have to learn yet another packaging stack or another upstream's
favourite container technology, so it's great that Icinga Web 2 is
packaged so that I can just install it without having to learn that. I
want it to be as easy as possible for the security team and the people
who care about it to keep it up to date. For the case where something
depends on OpenSSL, it's mostly pretty obvious where the trade-offs lie.
For the case where something depends on 80 npm libraries and a security
update to the application might require updating 10 of those and maybe
breaking some other packaged application in the process, it's not so
clear that it even serves our developers let alone our users.

[1] Disclaimer: I only do in-house development at work of Django
applications that aren't packaged in Debian, and I'm not involved in
Django's Debian maintenance, so this is an outside view and I may
have some details wrong.

Post by Tollef Fog Heen
You might still have to patch five versions of libvulnerable, but at
least it's possible to find which five versions are in use, and get
those fixed in a central place and then rebuild everything that's
vulnerable, recursively. Not the most fun job in the world, but it's
at least possible to automate somewhat.

So maybe what we need is to run with that a bit further? Debian has
historically been really good at coming up with ways to represent what
disparate upstream developers are doing in formats that can be consumed
in single common ways, so e.g. you can upgrade your system with a single
command rather than having to go and work out what to do for each
package. We could probably come up with a common format representing a
package's frozen dependencies, in the spirit of Built-Using, and see if
it's possible to build reasonable security workflows around those. For
instance, as a strawman starting point, we could aim for rules like
these:

* Constrained to the sort of server-side applications that might
reasonably be run in a container on their own, just to keep the
problem size down a bit.

* No freezing of stuff that's outside of the primary language ecosystem
involved (so your Python webapp doesn't get to come up with a fancy
way to vendor OpenSSL).

* Maybe truncate the frozen dependency tree at C extensions, in order
that we can make sure those are built for all architectures, so you'd
still have to care about compatibility with those. It'd be a much
smaller problem, though.

* Every frozen dependency must be installed in a particular defined
path based on (application name, dependency name, dependency
version), and must be installed using blessed tools that generate
appropriate packaging metadata that can be scanned centrally without
having to download lots of source packages.

* Updating a single frozen dependency (assuming no API changes to the
application's source code) must be no harder than updating a single
line in a single file and bumping the Debian package version.

* Where applicable, deprecation warnings must be configured as
warnings, not errors, to maximise compatibility.

* Dependencies with a non-trivial CVE history would have an acceptable
range of versions, so we could drop applications that persistently
cause trouble while still allowing a bit of slack. For some
dependencies it might not be a problem at all; e.g. we probably don't
care what version of python-testtools something uses.

* We put all this together in a separate archive that explicitly
doesn't have security support; the security team wouldn't be expected
to provide support until the tooling is in a state where it's easy
enough for them.

I dunno. Maybe this is all so much blowing smoke, since I'm not
actually volunteering ... but I develop webapps in the
frozen-dependencies style at work and still see value that a
distribution like Debian could provide by way of packaging, so wanted to
offer some suggestions that I think might be useful compromises.

[Holger Levsen]

Post by Colin Watson
* Constrained to the sort of server-side applications that might
reasonably be run in a container on their own, just to keep the
problem size down a bit.

why this contraint, there are more and more desktop application written in node...

[Colin Watson]

Post by Holger Levsen

Post by Colin Watson
* Constrained to the sort of server-side applications that might
reasonably be run in a container on their own, just to keep the
problem size down a bit.

why this contraint, there are more and more desktop application written in node...

I did say it was a strawman. I picked it mostly because trying to solve
every problem at once seems like a recipe for failure, though; better to
start small and expand once it's working.

[Steve McIntyre]

Post by Holger Levsen

Post by Colin Watson
* Constrained to the sort of server-side applications that might
reasonably be run in a container on their own, just to keep the
problem size down a bit.

why this contraint, there are more and more desktop application written in node...

Oh dear $deity, why?

[Robert Collins]

On 18 February 2018 at 12:14, Colin Watson <***@debian.org> wrote:
...

Post by Colin Watson
* Maybe truncate the frozen dependency tree at C extensions, in order
that we can make sure those are built for all architectures, so you'd
still have to care about compatibility with those. It'd be a much
smaller problem, though.

One case where this truncation would be a challenge is the Numpy and
scipy ecosystem, where the extensions are tightly coupled to blas
library used and the numpy ABI - because extensions built on top of
numpy depend on that ABI. pip has had difficulty shipping binaries of
these stacks because it doesn't represent the ABI - it assumed that
anything with a matching version number was compatible, which isn't
the case. Arguably numpy should do something different there, but it
doesn't :)

Post by Colin Watson
* Every frozen dependency must be installed in a particular defined
path based on (application name, dependency name, dependency
version), and must be installed using blessed tools that generate
appropriate packaging metadata that can be scanned centrally without
having to download lots of source packages.
* Updating a single frozen dependency (assuming no API changes to the
application's source code) must be no harder than updating a single
line in a single file and bumping the Debian package version.
* Where applicable, deprecation warnings must be configured as
warnings, not errors, to maximise compatibility.

Perahps its worth adding 'deprecations should be enabled if off by
default - at least during build-time' - I'm thinking of Python where
we (upstream) disabled deprecation warnings and many folk get
surprised as a result.

Post by Colin Watson
* Dependencies with a non-trivial CVE history would have an acceptable
range of versions, so we could drop applications that persistently
cause trouble while still allowing a bit of slack. For some
dependencies it might not be a problem at all; e.g. we probably don't
care what version of python-testtools something uses.

:P

-Rob

[Raphael Hertzog]

Post by Russ Allbery
The reason why Debian in general doesn't like to support vendored source
is because of the security implications: when there's a security
vulnerability in one of the vendored libraries, updating the relevant
packages becomes a nightmare. It's a logistical challenge even if the
vendored source can be safely upgraded, but of course it usually can't
since that's the whole point of vendoring the source. So we would be
faced with backporting security fixes to every vendored version of the
package, and we don't have the resources to do this.

We might not have the resources to do this but we should have the
infrastructure to track those problems, make them available to upstream,
and get them to fix their vendored libraries. And let users decide
whether it's safe to install or not, and track the security status over
time.

I don't agree that "vendored sources" cannot be safely upgraded. It really
depends on the reason why the source has been vendored. When it's a
deliberate fork, then yes the upgrade might be hard. But more often than
not, it's just a convenience to avoid system dependencies or a simple way
to ensure that the project has the version that they expect.

Furthermore many projects have continuous integration tools that let them
know whether things are still working after the update (be it because they
switched to latest upstream of all their dependencies, or because they
upgraded a library that they had vendored).

Post by Russ Allbery
It's hard to avoid the feeling that we have two choices with these sorts

I think Debian has never been afraid of tackling hard problems and we
should find a third way.

I don't want to lower the quality of what we have built so far, so while
it's technically possible to build .deb and include a bundle of libraries
pinned at the correct version, I don't think that this should allowed into
the main archive.

However I also think that Debian has to provide all those hard-to-package
applications to end users. Right now, my gut feeling is that the best
approach is probably to rely on containers built out of Debian
binary packages for the plumbing and with the language-specific package
management tool for the application libraries. The role of the Debian
developer is then to maintain a recipe file that is used to build the
container (and future updated versions) and to provide some integration
with the host to export/import data out of the application (think
backup/restore). Since Debian would start to provide many containers like
those, we would likely also start to build infrastructure to manage those
containers, including some way to identify security vulnerabilities
present in the container and a lintian for containers. And we would draft
a policy for how to manage an application in a container, etc.

Our core value is here and we can still provide value to our users in
the new world that is emerging around us. We should just stop to be afraid
of it.

Cheers,

[Paul Wise]

Post by Raphael Hertzog
I don't want to lower the quality of what we have built so far, so while
it's technically possible to build .deb and include a bundle of libraries
pinned at the correct version, I don't think that this should allowed into
the main archive.

The "not allowing embedded code copies in the main archive" ship has sailed:

https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies
https://wiki.debian.org/EmbeddedCodeCopies

[Raphael Hertzog]

Post by Paul Wise

Post by Raphael Hertzog
I don't want to lower the quality of what we have built so far, so while
it's technically possible to build .deb and include a bundle of libraries
pinned at the correct version, I don't think that this should allowed into
the main archive.

https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies
https://wiki.debian.org/EmbeddedCodeCopies

I know this but at least you have the sources in the source package. I was
referring to things like what I did in Kali for metasploit, it's a ruby
application. The .deb ships the metasploit code (available in the source
package) but also all the ruby libraries in a directory created with
"bundle install --vendor" and this includes lots of stuff... plain ruby
code but also binary extensions compiled on other systems and made
available as ready-to-download gems.

Sources:
http://git.kali.org/gitweb/?p=packages/metasploit-framework.git;a=shortlog;h=refs/heads/kali/master
Binary packages:
https://http.kali.org/pool/main/m/metasploit-framework/

Cheers,

[Alastair McKinstry]

Post by Raphael Hertzog
I think Debian has never been afraid of tackling hard problems and we
should find a third way.
I don't want to lower the quality of what we have built so far, so while
it's technically possible to build .deb and include a bundle of libraries
pinned at the correct version, I don't think that this should allowed into
the main archive.
However I also think that Debian has to provide all those hard-to-package
applications to end users. Right now, my gut feeling is that the best
approach is probably to rely on containers built out of Debian
binary packages for the plumbing and with the language-specific package
management tool for the application libraries. The role of the Debian
developer is then to maintain a recipe file that is used to build the
container (and future updated versions) and to provide some integration
with the host to export/import data out of the application (think
backup/restore). Since Debian would start to provide many containers like
those, we would likely also start to build infrastructure to manage those
containers, including some way to identify security vulnerabilities
present in the container and a lintian for containers. And we would draft
a policy for how to manage an application in a container, etc.

If we do this, we need to security-track the application libraries in
language-specific tools (e.g. pip), what are we dropping in quality
/work compared to auto-packaging from the language? while we don't
typically want to package 10,000 python packages for the sake of it, if
we need pyfoo (1.2) and are tracking it for security anyway, perhaps we
should write script python auto-packaging scripts,etc.

(Presuming licenses are automatically managed - taking license info from
pip / github, etc).

Post by Raphael Hertzog
Our core value is here and we can still provide value to our users in
the new world that is emerging around us. We should just stop to be afraid
of it.

[Holger Levsen]

I'd argue that what people should stop being afraid of is just using a third
party package if that's the optimal solution.

+1

[Michael Stone]

Post by Raphael Hertzog
Our core value is here and we can still provide value to our users in
the new world that is emerging around us. We should just stop to be afraid
of it.

I'd argue that what people should stop being afraid of is just using a
third party package if that's the optimal solution.

Mike Stone

[Sean Whitton]

Hello Paul,

Post by Paul Wise
I think the discussion we are having here is orthogonal to
containers/flatpaks.
If Debian were to have a repository of containers/flatpaks, then it
should meet Debian standards. We cannot just say "here are some
containers, completely unsupported and might not up to our standards".
To achieve that, I think it would be best to automatically convert it
from Debian binary packages. Also, since we are already doing
packaging work, it makes sense to base any container efforts on that,
just like our cloud efforts have been.
There is flathub, dockerhub etc for containers/flatpaks that may or
may not meet Debian standards.

I should have been more specific. What I was suggesting was that
providing a repository of containers/flatpaks/whatever would enable us
to provide different versions of libraries which would not receive
security support.

By having them in flatpaks/etc. we would mitigate somewhat the need for
this security support, and also draw a clear line between "this is the
stuff that we provide security support for" and "this is the stuff we
don't, but we've wrapped it up so it's a bit safer".

[Andreas Tille]

Post by Sean Whitton
We do not, and probably never
will have, the required manpower.

Since 2012 I'm maintaining a survey in wiki[1] where developers are
giving reasons why they entered Debian. I presented the result in
several talks the first time at FOSDEM 2013[2]. It boils down to the
very simple statement: A project like Debian Med which is de factor
very special and thus not very important to Debian was able to attract
more then one percent of the existing active Debian developers (we are
currently close to 2% five years later).

So if you are claiming we have no manpower that's pretty much our own
fault since we do not actively care. There are ways to attract gifted
and interested people if we would only try.

In the actual topic: If we simple hunting for adding random JS libraries
to the Debian package pool we will definitely fail technically and in
terms of attracting people who are working on the issue. If we in
contrast try to form a solid group which is reaching out to upstream and
try to get them actively involved we will be certainly able to solve the
issues we are facing today.

BTW, in the JS case I would rather take teams like Debian Perl team as
an example but they probably have not made a poll like the Debian Med
team.

Kind regards

Andreas.

[1] https://wiki.debian.org/DebianMed/Developers
[2] https://people.debian.org/~tille/talks/201302_fosdem_distro/
see page https://people.debian.org/~tille/talks/201302_fosdem_distro/debian-med_distro.pdf#page=51

[Sean Whitton]

Hello Andreas,

Post by Andreas Tille

We do not, and probably never will have, the required manpower.

So if you are claiming we have no manpower that's pretty much our own
fault since we do not actively care. There are ways to attract gifted
and interested people if we would only try.

I was making a more specific claim -- we don't and will never have the
manpower to provide security support for multiple different versions of
hundreds of little JavaScript libraries.

I don't doubt that we could have far more volunteers for other work if
we made it easier to get involved.

[Thorsten Alteholz]

Hi Sean,

Post by Sean Whitton
I was making a more specific claim -- we don't and will never have the
manpower to provide security support for multiple different versions of
hundreds of little JavaScript libraries.

please have a look at for example CVE-2017-18077 [1] in the security
tracker. This CVE affects one little JavaScript library and is marked as
<unimportant>. There is also a note attached, saying: "nodejs not covered
by security support"

Basically all other CVEs for node-modules are marked as <unimportant> as
well. So we do track all Javascript issues, but we don't create DSAs for
them and don't include them in point releases (as you can see for example
in CVE-2016-1000236 [2][3][4]).

Other javascript libraries like libjs-* and *.js even don't get a CVE. So
either they are secure or nobody cares.

Post by Sean Whitton
From a security manpower point of view, there is no difference whether we

have hundreds of little JavaScript libraries in only one or in multiple
versions.

Thorsten


[1] https://security-tracker.debian.org/tracker/CVE-2017-18077
[2] https://security-tracker.debian.org/tracker/CVE-2016-1000236
[3] https://nodesecurity.io/advisories/134
[4] https://tracker.debian.org/pkg/node-cookie-signature

[Paul Wise]

Post by Thorsten Alteholz
Other javascript libraries like libjs-* and *.js even don't get a CVE. So
either they are secure or nobody cares.

We also miss out on some JS vulnerabilities because NodeSecurity don't
systematically participate in the CVE system and we don't
systematically import their issues.

https://nodesecurity.io/advisories

[Andreas Tille]

Post by Sean Whitton

Post by Andreas Tille
So if you are claiming we have no manpower that's pretty much our own
fault since we do not actively care. There are ways to attract gifted
and interested people if we would only try.

I was making a more specific claim -- we don't and will never have the
manpower to provide security support for multiple different versions of
hundreds of little JavaScript libraries.

I agree that guessing from past experience chances are good that your
statement is true. But my claim was that we do not even try to find the
according manpower (for several urgent jobs that need to be done).

Post by Sean Whitton
I don't doubt that we could have far more volunteers for other work if
we made it easier to get involved.

So it would be good to try. :-)

Kind regards

Andreas.

[Michael Stone]

Post by Michael Meskes

Post by Michael Meskes
I know that this does create some problems for us, e.g. on the security
side, but the alternative is, as you mentioned, manually installed
software and that surely is worse.

No, I think it's better if people know they're on their own for maintaining
something. What's surely worse is when we ship stuff that we know we can't
properly maintain in the long term. Better to be out of the archive than in
without the expected level of quality.

Who said we cannot properly maintain this stuff?

Me, among others, based on experience watching what happens when this
stuff is packaged. The current "build everything from live git" paradigm
just doesn't work well for a package-based distributon with a multi-year
life cycle. Lots of people have tried, performed heroically, and thrown
in the towel when they realize the ongoing maintenance is even more
work than the initial heroic effort.

Mike Stone

[Michael Meskes]

Post by Michael Stone
stuff is packaged. The current "build everything from live git" paradigm
just doesn't work well for a package-based distributon with a multi-
year

True, that's why I think we should look for a different solutions.

Michael

[Michael Stone]

Post by Michael Meskes
True, that's why I think we should look for a different solutions.

There are different solutions, but the result isn't debian, it's
something else with a different set of expectations.

Mike Stone

[Michael Meskes]

Post by Michael Stone

Post by Michael Meskes
True, that's why I think we should look for a different solutions.

There are different solutions, but the result isn't debian, it's
something else with a different set of expectations.

Then I guess the question is, what is Debian?

Does a different and additional package format change the project?

Michael

[Michael Stone]

Post by Michael Meskes
Then I guess the question is, what is Debian?
Does a different and additional package format change the project?

It seems like you're not reading what other people have said--tt has
nothing to do with the packaging format, it has to do with providing a
stable base of software that interoperates. A collection of unrelated
independent modules which must be dynamically built off the latest git
repository may be interesting, but it's not a coherent distribution.
Other people are already trying to do that thing, it isn't clear what
value debian would add. Conversely, we know what the current debian
distribution provides, why throw that out to chase some new shiny thing?

Mike Stone

[Michael Meskes]

Post by Michael Stone

Post by Michael Meskes
Then I guess the question is, what is Debian?
Does a different and additional package format change the project?

It seems like you're not reading what other people have said--tt has

Well I try, but I'm certainly not perfect. Assuming this is not a
personal attack you might want to point me to whatever I missed.

Post by Michael Stone
nothing to do with the packaging format, it has to do with providing a
stable base of software that interoperates. A collection of
unrelated
independent modules which must be dynamically built off the latest git
repository may be interesting, but it's not a coherent distribution.

I thought we were talking about packages for some big applications that
a lot of people want to use nowadays.

Post by Michael Stone
Other people are already trying to do that thing, it isn't clear what
value debian would add. Conversely, we know what the current debian

How about making it available from the same reliable source? And having
it well integrated with the rest of the system?

Post by Michael Stone
distribution provides, why throw that out to chase some new shiny thing?

Sorry I still don't get this. Why would adding some (as Moritz
suggested probably less than 50) packages in a different format (Maybe
flatpak as Sean suggested) equal to throwing out what Debian provides
now?

Michael

[Gunnar Wolf]

Post by Michael Meskes

No, I think it's better if people know they're on their own for maintaining
something. What's surely worse is when we ship stuff that we know we can't
properly maintain in the long term. Better to be out of the archive than in
without the expected level of quality.

Who said we cannot properly maintain this stuff? And where do you
think our expected level of quality (whatever that is) will not be
reached?

In this thread, at least Raphaël and myself.

And, I guess, many others (say, OwnCloud was already brought up to
this thread).

[Michael Meskes]

Post by Gunnar Wolf

Post by Michael Meskes
Who said we cannot properly maintain this stuff? And where do you
think our expected level of quality (whatever that is) will not be
reached?

In this thread, at least Raphaël and myself.
And, I guess, many others (say, OwnCloud was already brought up to
this thread).

As I explained before the question was more about the definition of
"properly maintain".

Michael

[Adrian Bunk]

Post by Michael Meskes

Post by Michael Meskes
I know that this does create some problems for us, e.g. on the security
side, but the alternative is, as you mentioned, manually installed
software and that surely is worse.

No, I think it's better if people know they're on their own for maintaining
something. What's surely worse is when we ship stuff that we know we can't
properly maintain in the long term. Better to be out of the archive than in
without the expected level of quality.

Who said we cannot properly maintain this stuff? And where do you think our expected level of quality (whatever that is) will not be reached?

In the year 2018, any kind of "properly maintain" includes security support.

Please elaborate how Debian can provide security support for packages
like gitlab and all their dependencies in buster until mid-2022.

If Debian cannot provide security support for the lifetime of a stable
Debian release, it is better for our users when they are installing the
software from upstream with the security support provided by upstream.

Post by Michael Meskes
Michael

cu
Adrian

[Vincent Bernat]

Post by Adrian Bunk

Post by Michael Meskes
Who said we cannot properly maintain this stuff? And where do you
think our expected level of quality (whatever that is) will not be
reached?

In the year 2018, any kind of "properly maintain" includes security support.
Please elaborate how Debian can provide security support for packages
like gitlab and all their dependencies in buster until mid-2022.
If Debian cannot provide security support for the lifetime of a stable
Debian release, it is better for our users when they are installing the
software from upstream with the security support provided by upstream.

Debian is not only about security support. We provide packages without
security support. We also have backports that come without security
support either. This is still better than installing random packages
made by random people which may or may not integrate properly into
Debian.

[Adrian Bunk]

Post by Vincent Bernat

Post by Adrian Bunk

Post by Michael Meskes
Who said we cannot properly maintain this stuff? And where do you
think our expected level of quality (whatever that is) will not be
reached?

In the year 2018, any kind of "properly maintain" includes security support.
Please elaborate how Debian can provide security support for packages
like gitlab and all their dependencies in buster until mid-2022.
If Debian cannot provide security support for the lifetime of a stable
Debian release, it is better for our users when they are installing the
software from upstream with the security support provided by upstream.

Debian is not only about security support. We provide packages without
security support. We also have backports that come without security
support either. This is still better than installing random packages
made by random people which may or may not integrate properly into
Debian.

The software might integrate properly into Debian - and allow everyone
on the internet to take control of your computer.

On the server side we are talking about software like Node.js or gitlab.

On the desktop side the MUA that comes with our default desktop renders
HTML emails using a web engine that is not security supported by Debian.

An example what "no security support" means in practice:

If you are running Debian stable and haven't yet installed the
LibreOffice security updates Debian published a few days ago,
then opening a document is sufficient to make LibreOffice silently
send your gpg and ssh private keys to whatever server the author
of that document wants - no dialog, no warnings, you won't notice.

If Debian would provide LibreOffice without security support,
how many of our users would have been aware of this problem?

cu
Adrian

[Michael Meskes]

Post by Adrian Bunk
The software might integrate properly into Debian - and allow
everyone
on the internet to take control of your computer.

Which is of course independent of the way you install the software.
I don't think anyone suggest "no security", but something like
"security by upstream releases".

Michael

[Philipp Kern]

Post by Adrian Bunk
In the year 2018, any kind of "properly maintain" includes security support.
Please elaborate how Debian can provide security support for packages
like gitlab and all their dependencies in buster until mid-2022.
If Debian cannot provide security support for the lifetime of a stable
Debian release, it is better for our users when they are installing the
software from upstream with the security support provided by upstream.

Putting security support over all else is surely how some people see it.
But some upstreams also complain if you are going to ship ancient
versions because the most recent ones contain all of the fixes. It's
certainly more work to validate security fixes when backporting them to
older versions. So it's also the "stable" guarantee (whatever it is seen
as) that might need some re-adjustment.

One of the values is that you get some set of software that works
together as a base and doesn't change, but then people install software
on top of it that provides their service and if it's actually the thing
they want to provide it's most likely not packaged anymore at this
point. Because you'd want the latest features of the product you're
using. So there's already a disconnect of essentially two tracks: the
system's base at a solid version and whatever it is you want to offer at
a fast moving pace. That's also a reality in 2018. And coming up with
arbitrary deadlines of support are not all that helpful. Users don't
care if the ancient version of the software they need in stable is
security supported until mid-2022. If it doesn't satisfy their
requirements anymore, they move to testing or to another distribution.

Kind regards
Philipp Kern

[Adrian Bunk]

Post by Adrian Bunk
In the year 2018, any kind of "properly maintain" includes security support.
Please elaborate how Debian can provide security support for packages
like gitlab and all their dependencies in buster until mid-2022.
If Debian cannot provide security support for the lifetime of a stable
Debian release, it is better for our users when they are installing the
software from upstream with the security support provided by upstream.

Putting security support over all else is surely how some people see it. But
some upstreams also complain if you are going to ship ancient versions
because the most recent ones contain all of the fixes. It's certainly more
work to validate security fixes when backporting them to older versions. So
it's also the "stable" guarantee (whatever it is seen as) that might need
some re-adjustment.

Every change that gets published as DSA or part of a stable update gets
automatically installed on millions of machines.

One of the values is that you get some set of software that works together
as a base and doesn't change, but then people install software on top of it
that provides their service and if it's actually the thing they want to
provide it's most likely not packaged anymore at this point. Because you'd
want the latest features of the product you're using.

Sometimes that is true and sometimes it is not.
And what are the latest features today will likely be included in the
version in the next Debian stable.

The main question is what Debian can offer throughout the distribution.

Installing some or few (open source or proprietary) products on top of
the distribution is often required for various reasons.
If Debian ships an older version of one of these products that is not
a problem.

What is a problem is if such a 3rd party product suddenly breaks due
to an update in the stable distribution, or becomes vulnerable due to
unfixed CVEs in the stable distribution.

So there's already a
disconnect of essentially two tracks: the system's base at a solid version
and whatever it is you want to offer at a fast moving pace. That's also a
reality in 2018. And coming up with arbitrary deadlines of support are not
all that helpful. Users don't care if the ancient version of the software
they need in stable is security supported until mid-2022. If it doesn't
satisfy their requirements anymore, they move to testing or to another
distribution.

Let's make a real-life example:
salsa.debian.org and gitlab.

salsa currently runs a manually installed gitlab.
At some point after the release of buster salsa is expected to be
upgraded to buster.

If buster ships a gitlab package with no security support from Debian,
would you recommend that Debian uses this package on salsa until
bullseye gets released?

If buster ships a gitlab package that is supported by Debian by every
once in a while upgrading to the latest upstream gitlab, would you
recommend that Debian uses this package on salsa instead of continuing
to use a manually installed gitlab?

Even if gitlab would have been part of stretch it is clear that salsa
wouldn't use the version in stretch. The "ancient version of the
software" in buster will likely be recent enough for salsa, but for
such a central and exposed service security support and no regressions
are also important.

Kind regards
Philipp Kern

cu
Adrian

[Michael Meskes]

Post by Adrian Bunk

Post by Michael Meskes
Who said we cannot properly maintain this stuff? And where do you
think our expected level of quality (whatever that is) will not be
reached?

In the year 2018, any kind of "properly maintain" includes security support.

Indeed it does, but not necessarily the way we handle it now.

Post by Adrian Bunk
Please elaborate how Debian can provide security support for
packages
like gitlab and all their dependencies in buster until mid-2022.
If Debian cannot provide security support for the lifetime of a stable
Debian release, it is better for our users when they are installing the
software from upstream with the security support provided by
upstream.

Maybe you answered your question yourself. How about we tie our
security support to upstream's? Instead of fixing and backporting
ourselves we promise our users that this section of the archive will
get upstream's latest fixes even if that means the version number
changes.

This way the users would get a lot of benefits from using Debian but no
drawback compared to the self-installed alternative.

Michael

[Michael Stone]

Post by Michael Meskes
Maybe you answered your question yourself. How about we tie our
security support to upstream's? Instead of fixing and backporting
ourselves we promise our users that this section of the archive will
get upstream's latest fixes even if that means the version number
changes.

Because eventually a future version will come out that doesn't work with
the stable base, at which point we suddenly stop supporting the package.
That's much worse than just admitting up front that we can't support the
package for the next 4 years.

Mike Stone

[Michael Meskes]

Post by Michael Stone
Because eventually a future version will come out that doesn't work with
the stable base, at which point we suddenly stop supporting the package.
That's much worse than just admitting up front that we can't support the
package for the next 4 years.

Let's agree to disagree. I find it perfectly fine if we told people up
front that we support it as long as upstream has a version that works
with the stable base. They are still better or at least not worse of
with that than with a self-installed one.

Michael

[Michael Stone]

Post by Michael Meskes

Post by Michael Stone
Because eventually a future version will come out that doesn't work with
the stable base, at which point we suddenly stop supporting the package.
That's much worse than just admitting up front that we can't support the
package for the next 4 years.

Let's agree to disagree. I find it perfectly fine if we told people up
front that we support it as long as upstream has a version that works
with the stable base. They are still better or at least not worse of
with that than with a self-installed one.

Why? With the self-installed one they know up front that they need to
set up some kind of infrastructure to maintain it and can make an
informed decision about whether they want to take that on. How is it
better to think you have a debian supported install but in fact have to
come up with the very infrastructure you avoided on an emergency basis
at some point in the future?

Mike Stone

[Michael Meskes]

Post by Michael Stone

Post by Michael Meskes
Let's agree to disagree. I find it perfectly fine if we told people up
front that we support it as long as upstream has a version that works
with the stable base. They are still better or at least not worse of
with that than with a self-installed one.

Why? With the self-installed one they know up front that they need to
set up some kind of infrastructure to maintain it and can make an
informed decision about whether they want to take that on. How is it
better to think you have a debian supported install but in fact have to
come up with the very infrastructure you avoided on an emergency basis
at some point in the future?

I don't understand how this connects to what I, and others, were
saying. Nobody ever suggested to leave users in the dark, we talked
about documenting very clearly what they get and what they don't.
Besides my personal experience is that most people do not set up the
infrastructure you mentioned so they get caught unaware no matter what.

Michael

[Adrian Bunk]

Post by Michael Meskes

Post by Michael Stone
Because eventually a future version will come out that doesn't work with
the stable base, at which point we suddenly stop supporting the package.
That's much worse than just admitting up front that we can't support the
package for the next 4 years.

Let's agree to disagree. I find it perfectly fine if we told people up
front that we support it as long as upstream has a version that works
with the stable base. They are still better or at least not worse of
with that than with a self-installed one.

They are not.

Ideally Debian should provide and support the software, but support that
might suddenly go away without any clear option forward is the worst
option Debian could offer.

What is the user supposed to do when Debian announces that some
software essential for that user is no longer supported in the
stable release the user is using?

At that point the options for the user are either to continue using
software that might already have known grave vulnerabilities, or to
do a rushed attempt trying to find some way to self-install an upstream
version that is still supported.

This is clearly worse than using a self-installed version from the
start, which gives the user the knowledge how to use the self-installed
version (that might differ from how Debian provides the software) and
gives a clear picture from the start when upgrades to new major versions
will have to be planned.

Post by Michael Meskes
Michael

cu
Adrian

[Michael Meskes]

Post by Adrian Bunk
What is the user supposed to do when Debian announces that some
software essential for that user is no longer supported in the
stable release the user is using?

Again, where does this differ from the user realizing their own self-
baked installation cannot be upgraded anymore?

Post by Adrian Bunk
At that point the options for the user are either to continue using
software that might already have known grave vulnerabilities, or to
do a rushed attempt trying to find some way to self-install an
upstream
version that is still supported.

And why wouldn't we offer said upstream version instead of the
unsupported older one?

Michael

[Gunnar Wolf]

Post by Michael Meskes
Can't we treat a .deb file like a container in the sense that it may
include additional source if needed? I'd very much like this.
I know that this does create some problems for us, e.g. on the security
side, but the alternative is, as you mentioned, manually installed
software and that surely is worse.

Dunno.

As a sysadmin, I know I can trust that most of my system is OK if I
just apt update / apt upgrade every so often. And I know the maybe
five to ten software packages I have hand-installed. I know I must be
aware of their alerts and whatnot.

I know that being a 15-year DD does not make me the average
sysadmin. But that's one of Debian core values to sysadmins. I guess
I'm not the only one appreciating that.

[Michael Meskes]

Post by Gunnar Wolf
As a sysadmin, I know I can trust that most of my system is OK if I
just apt update / apt upgrade every so often. And I know the maybe
five to ten software packages I have hand-installed. I know I must be
aware of their alerts and whatnot.

Personally I'm afraid that a lot of sysadmins know to run apt
update/upgrade frequently but way fewer do (have the time to) check the
alerts etc.

Michael

[Andrey Rahmatullin]

Recently on Planet: https://apebox.org/wordpress/linux/1229

[Ghislain Vaillant]

Post by Raphael Hertzog
Hello everybody,
the fact that I had to request the removal of dolibarr from Debian makes
me sad (see below for the reasons) and I believe that we should be able
to do better to provide complex applications to our end users.

I feel your pain too and agree with your assessment.

Post by Raphael Hertzog
- while gitlab is packaged in Debian, its packaging took years and the
result is brittle because it can break in many ways whenever one the
dozens of dependencies gets updated to some new upstream version
(BTW salsa.debian.org does not use the official package)
- I have the Debian packaging of distro-tracker (the code behind
tracker.debian.org) available in the git repository for years
but I never released it into Debian because it embeds a few
javascript
libraries (bootstrap, jquery) and I don't want to validate that
it does work with the versions currently in Debian
I'm sure we are missing lots of good applications due to our
requirements.
What can we do to avoid this?

The problem also comes from the disconnect between current software
development practices: relying on libraries pinned to a specific
version, or with unstable APIs, or vendored to the code base, and the
ideal proned by Debian: a centralized repository of dependencies which
all applications should be built with.

The situation is particularly visible with the Javascript ecosystem,
but similar problems are appearing in the Python and Ruby world.

Post by Raphael Hertzog
I don't have any definite answers although there are ideas to
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

In particular for non-compiled libraries kept private to the
application. These should represent a lower threat vector than say,
multiple vendored copies of openssl or zlib.

Post by Raphael Hertzog
- we could ship those applications not as .deb but as container
and let them have their own lifecycle

Not sure what you mean, but I trust you on that.

Post by Raphael Hertzog
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

Or do our best to support alternative means of installing software such
as docker, snap or flatpak.

Post by Raphael Hertzog
Cheers,

Post by Raphaël Hertzog
Package: ftp.debian.org
Severity: normal
I'm the usual sponsor of dolibarr in Debian. The maintainer (and
upstream author) Eldy Destailleur announced me a few weeks ago that he
will no longer be maintaining Dolibarr within Debian because it was
too much of a pain to respect all the Debian requirements.
He explained to me that Dolibarr relies on 15 javascripts libraries (some of them
are dependencies of the libraries that Dolibarr are using in the first
place) and 5 PHP libraries.
Debian's requirement to provide a non-minified copy of the
javascript is
really hard to meet for him because often the projects are only providing
the sources under the form a github link (and not under the form of
a non-minified javascript that we could put next to the minified file to
please lintian). He would have to spend a lot of times with the different
upstreams to get them to provide the non-minified file in a form that is
suitable for Debian. It's even likely that his requests would be dismissed
by multiple upstream authors leaving him in the inconvenient
position of
having to remove features to be able to ship a policy-compliant Debian
package.
The requirement to use packaged versions of all the libraries is also
problematic. More often that not the version used by Dolibarr will not
match the version currently available in Debian and it's always a risk
to use a different version. Sometimes it will work just fine, sometimes it
will break.
Given all those constraints, he decided to stop trying to maintain
Dolibarr in Debian and the Dolibarr project will only provide an
unofficial .deb embedding all the libraries that they need.
I doubt anyone else is willing to maintain Dolibarr in Debian and I'm
thus requesting the package to be removed. Users are better served
by the upstream unofficial package rather than by Debian's outdated
package (it's outdated due to the difficulty of updating it in a
policy-compliant way).
I would hope that we could find a way to get the best of both worlds
but right now it seems that we don't have a good solution for that kind
of web application.
Thank you.

[Innocent De Marchi]

Hello everybody,

Post by Raphael Hertzog
I'm sure we are missing lots of good applications due to our
requirements. What can we do to avoid this?

Is it a goal of Debian to accumulate applications? It is a priority to
offer a robust and solid system: Other Debian derivatives accept
relaxations: I think Debian must maintain its line.

I believe that the right way is to
convince developers of the need to generate applications that respect
the principles of free code.
And another strategy, is to get developers to write "specifically" for
Debian.


Regards!

I. De Marchi

[Andrey Rahmatullin]

Post by Innocent De Marchi
I believe that the right way is to
convince developers of the need to generate applications that respect
the principles of free code.

Note that we don't want "applications that respect the principles of free
code", we specifically require DFSG, and a specific interpretation of it,
which is not the same as just "free software"/"open source".

Post by Innocent De Marchi
And another strategy, is to get developers to write "specifically" for
Debian.

I don't think this is feasible.

[Jonathan Carter (highvoltage)]

Hi Raphael

Post by Raphael Hertzog
- while gitlab is packaged in Debian, its packaging took years and the
result is brittle because it can break in many ways whenever one the
dozens of dependencies gets updated to some new upstream version
(BTW salsa.debian.org does not use the official package)
- I have the Debian packaging of distro-tracker (the code behind
tracker.debian.org) available in the git repository for years
but I never released it into Debian because it embeds a few javascript
libraries (bootstrap, jquery) and I don't want to validate that
it does work with the versions currently in Debian
I'm sure we are missing lots of good applications due to our requirements.
What can we do to avoid this?

How can we avoid upstream not making source available for their
binaries? Because this is fundamentally the issue with shipping only
minified javascript without any sources or reference of where it comes
from. This also isn't a problem in Debian, it's a broken JavaScript
ecosystem that's driven by very poor software developers who tend to
want to smack together anything that will work for a little while so
that they can get paid for their work and move on to the next bad project.

Post by Raphael Hertzog
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

Which requirements are you referring to? If it's relaxing the need for
source for minified javascript, then no thanks.

Post by Raphael Hertzog
- we could ship those applications not as .deb but as container
and let them have their own lifecycle

What would this solve and how will it solve it?

Post by Raphael Hertzog
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

As someone who intends to package software that contains some embedded
low-quality JavaScript code, yes, certainly frustrated. But with the
JavaScript community and their underdeveloped ideas of how software
works, not with Debian.

-Jonathan

[Samuel Thibault]

Post by Jonathan Carter (highvoltage)

Post by Raphael Hertzog
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

Which requirements are you referring to? If it's relaxing the need for
source for minified javascript, then no thanks.

Instead of requiring the source to be provided in the source package as a
non-minified file, we could require the packager to document in
debian/README.source where the upstream sources actually are.

But what if that upstream website goes down? We don't have the source
any more. Better at least keep a copy of the tarball.

Samuel

[Samuel Thibault]

Post by Samuel Thibault
But what if that upstream website goes down? We don't have the source
any more. Better at least keep a copy of the tarball.

Sure. But as a packager, I don't want to have to do this manually. So
one possible idea might be to extend our copyright file format. We should
be able to put there the URL for the sources of something that has been
embedded in the application

Or simply some debian/rules lines, so that it's at the time of the
packaging? (like the common get-orig rule)

Samuel

[Alastair McKinstry]

Post by Samuel Thibault

Post by Jonathan Carter (highvoltage)

Post by Raphael Hertzog
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

Which requirements are you referring to? If it's relaxing the need for
source for minified javascript, then no thanks.

Instead of requiring the source to be provided in the source package as a
non-minified file, we could require the packager to document in
debian/README.source where the upstream sources actually are.

But what if that upstream website goes down? We don't have the source
any more. Better at least keep a copy of the tarball.

I second this, for multiple reasons. If we go to a 'container capturing
a non-Debian build' approach we should always capture the sources
involved - for security tracking at least. e.g. Maven for Java seems to
be particularly bad at pulling JARs and other components randomly, often
over HTTP not HTTPS and without signatures, etc.  Gradle even does <pull
fragment of code from http:x and insert here> which is scary.

One step towards a fully proper Debian build and packaging is an 
infrastructure to at least capture all the sources involved in
containers and track them.

Post by Samuel Thibault
Samuel

Alastair

[Raphael Hertzog]

Post by Samuel Thibault

Post by Jonathan Carter (highvoltage)

Post by Raphael Hertzog
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

Which requirements are you referring to? If it's relaxing the need for
source for minified javascript, then no thanks.

Instead of requiring the source to be provided in the source package as a
non-minified file, we could require the packager to document in
debian/README.source where the upstream sources actually are.

But what if that upstream website goes down? We don't have the source
any more. Better at least keep a copy of the tarball.

Sure. But as a packager, I don't want to have to do this manually. So
one possible idea might be to extend our copyright file format. We should
be able to put there the URL for the sources of something that has been
embedded in the application and some debian.org service would ensure that
we keep a publicly-accessible copy of all those sources for as long as we
want them.

BTW we could also rely on our copyright file to document the fact that we
have vendored copies of some software.

Cheers,

[Raphael Hertzog]

Post by Jonathan Carter (highvoltage)

Post by Raphael Hertzog
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)

Which requirements are you referring to? If it's relaxing the need for
source for minified javascript, then no thanks.

Instead of requiring the source to be provided in the source package as a
non-minified file, we could require the packager to document in
debian/README.source where the upstream sources actually are.

When I was maintaining wordpress, I introduced the idea of providing
debian/missing-sources/ to comply with the Debian policy. I would just dump
there the upstream tarball of the bundled libraries to be sure that we
have the source for the correct version. The Debian/ftpmaster rules are
respected but it's not really better than the above because you still
don't have a simple way to rebuild a modified version of the javascript
library shipped in the package.

So instead of ugly work-arounds, it might be better to just acknowledge
that we can't have the same level of support for all applications.

Post by Jonathan Carter (highvoltage)

Post by Raphael Hertzog
- we could ship those applications not as .deb but as container
and let them have their own lifecycle

What would this solve and how will it solve it?

Those applications could rely on the package manager of their ecosystem to
setup the dependencies as they need them without polluting the host
system.

Cheers,

[Adam Borowski]

Instead of requiring the source to be provided in the source package as a
non-minified file, we could require the packager to document in
debian/README.source where the upstream sources actually are.

Ie, it'd be fine to ship pre-built C libraries as long as some non-buildable
sources were once placed at website X?

[Gunnar Wolf]

Post by Raphael Hertzog
Hello everybody,
the fact that I had to request the removal of dolibarr from Debian makes
me sad (see below for the reasons) and I believe that we should be able
to do better to provide complex applications to our end users.
(...)
I'm sure we are missing lots of good applications due to our requirements.
What can we do to avoid this?
(...)
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

I was bitten by a similar issue; I maintained Drupal 7 for several
years (was included in 3 stable releases). But I gave up when
packaging Drupal 8, much for the same reasons:

http://gwolf.org/node/4087

However it saddens me, that's... Well, the right thing to do, IMO.

Post by Raphael Hertzog
- we could relax our requirements and have a way to document the
limitations of those packages (wrt our usual policies)
- we could ship those applications not as .deb but as container
and let them have their own lifecycle

I would not like us relaxing our requirements. If there is a need to
distribute webapps as container images, that can be done, and much
probably it can be done by ourselves - But that's not Debian. That
means, distributing a container with dolibarr or with drupal8 will not
allow us to build packages that depend on them (such as
drupal7-mod-civicrm), or packaging helpers (such as
dh-make-drupal). Maybe few webapps introduce full ecosystems as Drupal
does; we had a similar issue a couple of years ago with OwnCloud, and
it would fall in the same case. And I think examples will be too many
to list.

[Paul Wise]

Post by Raphael Hertzog
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

I think we should keep software that doesn't meet our standards
outside of Debian. There are plenty of ways to deploy such software,
we do not need to diverge from upstream's deployment methods
(containers etc) unless that software is suitable for packaging within
Debian; under a free license, source-only tarballs/VCS available,
builds everything from source, no embedded code/data copies etc. These
are violated a *lot* already for packages already in Debian, I think
we should aim to reduce that rather than increase it.

[Moritz Mühlenhoff]

Post by Raphael Hertzog
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

There's clearly a set of software which is of high quality, but where
upstream's development practices are not usefully aligned with our
existing distro model. This goes beyond web applications, we're also
missing out top quality server software (e.g. elasticsearch which
also turned out to be incompatible, see the PTS for details)

Many of those upstreams provide custom debs or have people install
locally instead, but IMO we should still strive to accomodate these
packages:
- by providing a well-maintained common base stack underneath
(Java, core system services, PHP, Curl etc. pp.)
- by ensuring our usual high standards of FLOSS compliance

One way would be to create a new archive section which is based on
the latest stable release, which
- follows upstream releases/branches independant of the Debian
lifetime (for users of such software it's common to have releases
being supported for only a year or so and being forced to upgrade
more often)
- allows maintainers to release updates independant of the stable
release managers and the security team
- allows bundling some classes within the specific packages if
those need to be more recent than what the stable base provides
(we can track code copies etc)

I don't think this section would contain more than, say 50 packages,
but would Debian to sensibly provide packages for say Nextcloud,
the Elastic stack or Grafana (or even gitlab, while packaged
in stretch, salsa also follows upstream and even backporting
the first set of security fixes isn't done after a month (#888508).

Cheers,
Moritz

[Craig Small]

Post by Raphael Hertzog
I'm sure we are missing lots of good applications due to our requirements.
What can we do to avoid this?

[...]

Post by Raphael Hertzog
What do you think? Do you have other ideas? Are there other persons
who are annoyed by the current situation?

I'd like to start this with, I don't have an answer. However it is annoying!

I have wordpress that ships some javascript libraries purely because the
ones in Debian are ancient or not packaged. Ideally I'd like to use to
just depend on some other packages but the problem is, is the javascript
library shipped by wordpress the same as the upstream? Certainly
dh_linktree (thanks Raphael!) help here, but its a problem I don't want to
encounter.

Then I have another program. It's written in C++ so most of that side of
things is fine, but it uses Lua plugins and this is where the drama starts.
I just ship with the embedded ones, because version control of the
(hypothetical) lua library packages and syncing it with whatever arbitary
version of the library the program needs is hard.

Finally, for programs I write and use myself, if its a C program I'm pretty
sure I'll find what I need for libraries, but in other languages not so
much.

In the ancient days, we used to have some of these problems with binaries
and shared libraries. Then newer, for their time, distributions such as
Debian came in with versioned dependencies between the binary and the
library. That didn't help when upstream used their own hacky un-maintained
for years version of some library but it caught most of the cases.

So, perhaps there needs to be a new way for some of these newer packaging
methods. I don't think we can say package all the things, even Debian has
its limits.

- Craig

[Pirate Praveen]

Post by Raphael Hertzog
- while gitlab is packaged in Debian, its packaging took years and the
result is brittle because it can break in many ways whenever one the
dozens of dependencies gets updated to some new upstream version
(BTW salsa.debian.org does not use the official package)

I maintain complex packages like gitlab and diaspora and I agree about
the amount of work required. But the reason why library updates break
can be improved by two steps.

1. Enable functionality tests for all dependencies (we already have
pretty good test coverage and that should be increased).
2. Find out about possible breakages before the upload.
This can be achieved by using scripts like build-and-upload which runs
autopkgtests of all reverse dependencies and rebuilds all reverse
dependencies. Unfortunately use of this script is not wide spread yet
and we need to include it in a commonly used package like devscripts.
Many if the recent breakages could have been avoided if the uploaders
used this option.
3. When introducing a breaking change, we need to help upstreams to move
to the new version along with us. This is not different from how we
handle transitions, but the number of transitions will increase.

Post by Raphael Hertzog
I'm sure we are missing lots of good applications due to our requirements.
What can we do to avoid this?

I think the situation regarding javascript have improved largely in last
two years. It took me more than 2 years to get handlebars in debian
because none of the build tools were packaged. Now with many common
build tools like grunt, gulp, webpack, rollup, babel etc packaged, the
effort required to package a new library has significantly reduced (a
complex library like react took only a fraction of time required for
handlebars). I believe this will encourage more people to start
maintaining javascript libraries as the barrier of entry has been
reduced significantly. Case before two years was reverse engineering the
build system using tools like sed, which is not the case now.

As for the number of packages to maintain is very large, I realized it
would be hard for me to maintain these long dependencies alone, so I
have been aggressively seeking and mentoring more people to maintain
packages. I have organized countless offline and online packaging
sessions. I have reasonable success (compared to the effort I put in)
and hope to continue those efforts.

We not only have to get more people to package, but since upstream is
not listening to us, we need to get more people to help with fixing
upstream compatibility issues too.

I have got some very good help from people like Shanavas, Jishnu, Aruna
and Harish to make upstream compatible with the library versions we have
in debian (moving handlebars to babel 6 and webpack 3, moving many
libraries to chai 4, adding global library support to grunt, etc to name
a few). They have been helping with node specific issue and got upstream
to accept pull requests. In other pending cases, even though they don't
help us, they are willing to take pull requests.

Also I have decided to package a module only if a at least two packages
depend on it, which will speed up the process and also reduce the load
on ftp masters (please help ftp masters review the long queue if you can).

See
https://salsa.debian.org/js-team/node-ava/tree/master/debian/node_modules

(some of those currently embedded there will need to be packaged
separately because they are generated files. But if a module is pure es5
and required only for one module it could be embedded. Also in newer
nodejs versions we may be able to do this with es6 modules too).