Re: Package dependency versions and consistency
On Fri, Dec 18, 2020 at 04:25:19PM -0800, Josh Triplett wrote:
>...
> I'm not suggesting there should be 50 versions of a given
> library in the archive, but allowing 2-4 versions would greatly simplify
> packaging, and would allow such unification efforts to take place
> incrementally, via transitions *in the archive* and *in collaboration
> with upstream*, rather than *all at once before a new package can be
> uploaded*.
>
> (I also *completely* understand pushing back on having 2-4 versions of
> something like OpenSSL; that'd be a huge maintenance and security
> burden. That doesn't mean we couldn't have 2-4 semver-major versions of
> a library to emit ANSI color codes, and handle reducing that number via
> incremental porting in the archive rather than via prohibition in
> advance.)
It is important to always remember that the main product we are
delivering to our users are our stable releases.
Right now we are close to the freeze of bullseye.
We will security-support bullseye until mid-2024.
We do have 4 different versions of autoconf in the archive.
This works because autoconf does not have CVEs.
If a library is so complex that your "unification efforts in
collaboration with upstream" would apply, chances are there
will be CVEs if anyone does a security audit of the code.
> I think much of our resistance to allowing 2-4 distinct semver-major
> versions of a given library comes down to ELF shared libraries making it
> painful to have two versions of a library with distinct SONAMEs loaded
> at once, and while that can be worked around with symbol versioning,
> we've collectively experienced enough pain in such cases that we're
> hesitant to encourage it. Our policies have done a fair bit to mitigate
> that pain. But much of that pain is specific to ELF shared libraries and
> similar.
No, the only real pain is providing security support.
>...
> The
> dependency and library mechanisms of some other ecosystems, are designed
> to support having multiple distinct versions of libraries in the same
> address space, with fully automatic equivalents of symbol versioning.
>...
How can Debian security support packages from such ecosystems?
To meit always feels as if these ecosystems are not interested in
providing any support for that.
The basic idea behind a distribution like Debian stable or Ubuntu LTS
is to provide one set of packages, which will then stay unchanged for
3 or 5 years except for security fixes.
There are usecases for rolling release distributions,
and there are usecases for stable distributions like Debian.
If there is a CVE in a library that is used by 20 different packages
in 20 different versions, how does the ecosystem help Debian with
applying this CVE fix to all 20 versions with reasonable effort?
> - Josh Triplett
cu
Adrian
Reply to: