Re: Package dependency versions and consistency
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.)
Some non-C languages (notably Perl and Python) have a single system-wide
search path and cannot easily accommodate more than one major version
unless they have different names (libdancer-perl, libdancer2-perl;
python3-boto, python3-boto3). 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.
The GObject-Introspection bindings for GLib-based libraries like GTK
are another example of this, if you look at them from an appropriate angle:
for example, the gir1.2-gtk-3.0 package contains Gtk-3.0.typelib, which
is installable in parallel with Gtk-2.0.typelib and Gtk-4.0.typelib.
smcv
Reply to: