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
