Package: debhelper
Version: 13
Severity: wishlist
We recently had some crash bugs reported against GNOME (#958017, #958025)
which turned out to involve a minimal partial upgrade from stable to
testing/unstable.
On one hand, partial upgrades from stable to testing/unstable need to
be at least vaguely supported (working well enough to run maintainer
scripts), because they will exist as transitional states during a full
upgrade (in particular, from oldstable to stable after the testing
distribution gets released) - so if particular combinations of packages
that can't work together are identified, then that's a bug, and in
principle we should fix it, either by tightening positive and negative
dependencies (mainly Depends and Breaks) or by changing code to make it
more tolerant.
On the other hand, arbitrary partial upgrades from stable to
testing/unstable are not feasible to support with finite developer
effort available, because there's a combinatorial explosion of possible
combinations of packages. So, pragmatically, we should not encourage
users to perform partial upgrades, and the majority of bugs of that
class will go undetected and unfixed.
One type of partial upgrade that is particularly problematic (which did
happen in the case of #958017) is if the user selects some but not all
of the binary packages built by a source package for upgrade. This is
not something that the upstream developers of a package are ever going
to support, and I don't think it's something that Debian should make any
attempt to support either, because it's very common for interdependent
binary packages from the same source to "know" that they are installed
with matching versions, and make use of assumptions or implementation
details that are outside the package's public interface.
pango in #958017 was a good example: the various libraries built by
src:pango1.0 share headers like pango/pango-fontset-private.h, and will
crash if they don't all agree on the struct layouts in those headers.
I've fixed this in src:pango1.0 (and several other GNOME libraries,
not uploaded yet) by adding a d/shlibs.local that gives the libraries
lockstep dependencies on each other, but I can't help thinking this is
something that debhelper could be doing for us.
Two implementation options spring to mind:
- generate a shlibs.local (possibly by altering an existing,
hand-written shlibs.local) and pass that to dpkg-shlibdeps -L;
- postprocess the dpkg-shlibdeps output to convert
LIBNAME (>= x) into LIBNAME (= ${binary:Version}) for each
LIBNAME that is a binary package built by this source
Does this seem a reasonable debhelper feature?
Thanks,
smcv
