Re: Package dependency versions and consistency
On Sat, Dec 26, 2020 at 02:55:17PM -0800, Josh Triplett wrote:
>...
> If you want to package abc version 1.2.3, and among many other things,
> abc depends on xyz version 2.1.4, and xyz has a new version 3.0.1 now,
> it makes sense to work with the upstream of abc, sending them a patch to
> migrate to the new version, and waiting for abc 1.2.4 to come out with
> that update. It *doesn't* make sense to maintain a downstream Debian
> patch to make abc work with the newer xyz.
Maintaining a backported patch is usually very cheap,
it can just be dropped when updating to abc >= 1.2.4.
> abc can just build-depend on
> xyz-2, and a later version of abc can build-depend on xyz-3. That isn't
> a reflection of complexity in xyz, or in abc.
It is usually a reflection of very poor API design in xyz.
The whole semver approach in general seems to discourage proper API
design and encourage breaking changes all the time.
Python 2 and Python 3 also have a semver mechanism, and while the semver
mechanism permitted a transition over more than a decade it did not
reduce the enormous amount of work for eventually migrating most code
from the old version to the new version.
The Python ecosystem has learned the hard way how horrible breaking
changes can be even when there is a semver mechanism, and noone would
dare to suggest a similar amount of breakage for Python 4.
>...
> By contrast with that, security support may not be nearly as much of an
> issue. The *majority* of libraries in Debian don't require any security
> updates at all.
My basic assumption would be that any code that might handle untrusted
input is only one security audit away from a CVE.
>...
> I'm not talking about packaging xyz 1.2.3, 1.2.4, 1.3.1, and 2.0.1. When
> xyz 1.3.1 is uploaded, it can safely replace 1.2.4,
In stable this is not safe.
How can you ensure that upgrading from 1.2.4 to 1.3.1 would not cause
any regressions?
Security updates get automatically installed to production environments
and deployed devices of users.
If xyz 1.2.4 in stable has a CVE that is fixed in 1.3.1, to minimize
the risk of regressions the usual approach is to do the minimal fix
of applying the CVE fix only to 1.2.4.
> and packages using xyz 1.2.4 can get rebuilt via binNMU if needed.
This is also a huge problem.
The way a distribution like Debian works, I do not see how security
support would be possible for a static-only ecosystem with a non-trivial
number of packages.
Imagine the C/C++ ecosystem would also be an ecosystem without shared
libraries.
Currently there are over 30k source packages in bullseye that build
architecture-specific binary packages for amd64.
Every security fix for glibc would require rebuilding more than 30k
packages for all release architectures in stable.
A normal user has over 1k architecture-specific binary packages installed.
Every security fix for glibc would require every user to download
and upgrade more than 1k packages.
>...
> - Josh Triplett
cu
Adrian
Reply to: