Re: Package dependency versions and consistency
Simon McVittie wrote:
> On Sat, 26 Dec 2020 at 14:55:17 -0800, Josh Triplett wrote:
> > I'm talking about packaging xyz 1.3.1 and 2.0.1, as separate xyz-1 and
> > xyz-2 packages, and allowing the use of both in build dependencies.
>
> This is not all that rare even for C/C++ code, as exemplified by
> GTK and other libraries that follow the principles described in
> <https://ometer.com/parallel.html> (written by a then-maintainer of
> GTK during the GTK 1.2 to GTK 2 transition). A few examples: GTK, SDL,
> libpcre, Allegro, Boost, LLVM, libftdi, libfuse, mozjs; and historically
> we also had this for GStreamer, Qt, OpenSSL and WebKitGTK among others.
>
> We try to minimize the number of parallel-installable versions of a
> particular library because maintainers and the security team can only
> parallelize so far, but the extent to which we can do this depends on
> balancing several factors, including the effort required to maintain those
> versions, the extent to which they are exposed at security boundaries,
> the extent of the incompatibilities, the effort needed and available
> upstream or downstream to port all dependent libraries and programs
> to the currently-recommended version, and the extent to which we could
> accept losing packages still dependent on the old version from Debian.
> For example, the Qt/KDE team were able to drop Qt 4 from Debian between
> Debian 10 and 11, but GTK 2 certainly can't get the same treatment until
> there is a stable release of GIMP that uses GTK 3 or later.
>
> I can see that in language ecosystems that encourage more/smaller packages
> than C/C++, or that break API more frequently, we have a scaling problem:
> GTK has historically had a new major version about once a decade, which
> doesn't represent too many trips through NEW even if it speeds up by
> an order of magnitude, but the library ecosystems we're discussing on
> this thread are presumably expected to break API/ABI rather more often
> than that. (To an extent, typical C/C++ tooling accidentally protects
> us from this, by making it so painful to break API/ABI that maintainers
> go to great lengths to avoid it.)
Exactly; complete agreement with everything you've written here. Even
with as painful as it is with C libraries, we've still done it. But with
some other languages, which make it substantially less painful, current
practice (NEW, and package rejections) nonetheless pushes back much more
strongly on co-installable packages.
> However, if a language has a way to ask for a library by its (name,
> major version) pair, it would seem sensible for any Debian-specific
> machinery around it to usually map (name, major version) pairs (as
> opposed to bare names) to installation filenames/directories and
> Debian package names.
This is exactly what I'm proposing (along with dropping the aversion to
small, separately-packaged libraries, and the pressure to bundle them
together in fewer source or binary packages). If the packages would
otherwise be co-installable, it should be possible to upload multiple
major versions as separate packages, and we should leave it up to the
judgment of the package maintainer whether it's appropriate for multiple
versions to coexist or not. Policy should provide guidance, in the form
of the many factors you mentioned above, and we can still *encourage*
developers to reduce proliferation by porting software to newer versions
(not to older versions).
We also need to reduce the overhead of NEW for both package maintainers
and package reviewers, at least for the case where the primary reason
the package hits NEW is that the major version (and thus the package
name) has changed. That includes the case where the new major version
has a corresponding new source package, but the source package is
derived from the previous source package. A package in the archive can
always have an RC bug filed on it later, if an issue arises.
- Josh Triplett
Reply to: