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
