Re: DEP 17: Improve support for directory aliasing in dpkg
On Fri, 21 Apr 2023 at 15:29:33 +0100, Luca Boccassi wrote:
> After Bookworm ships I plan to propose a policy change to the CTTE and
> policy maintainers to forbid shipping files in the legacy directories
> altogether, followed by a debhelper change to adjust any stragglers
> automatically at build time and a mass rebuild
That seems quite likely to trigger the scenario Helmut is trying to avoid,
which if I understand correctly is this:
* foo_12.0 in Debian 12 ships /lib/abcd
* bar_13.0 takes over /lib/abcd from foo, but because of either your
proposed change or a manual action by the maintainer, it is actually in
the data.tar as ./usr/lib/abcd (not ./lib/abcd like it was in foo_12.0)
* the maintainer of bar didn't add the correct Breaks/Replaces on foo
* a user upgrading from Debian 12 to 13 installs bar_13.0, perhaps pulled
in as a dependency
* expected result: dpkg refuses to unpack bar ("trying to overwrite ..."),
the upgrade is cancelled, and the user reports a RC bug in bar
* actual result: /usr/lib/abcd in bar quietly overwrites /lib/abcd from foo
* if bar is subsequently removed, then dpkg (and therefore apt) thinks foo
is fully functional, but in fact /{usr/,}lib/abcd is missing
(For simplicity I've described that scenario in terms of files directly
shipped in the data.tar, but dpkg also tracks the ownership of files
created by dpkg-divert or alternatives, and similar things can happen
to those.)
I had hoped that the last section of technical committee resolution
#994388 (which concerns this situation) would become irrelevant in Debian
13, but it's looking as though without the sort of dpkg changes discussed
in this thread, the concern about files moving between packages would
remain a valid concern.
However, as far as I can see, the other reasons not to do this that were
mentioned in the last section of #994388 *do* become irrelevant in Debian
13, so solving the files-moved-between-packages thing is the last major
blocker for doing what you propose. (Unless someone has a reason why this
is not the case?)
You might reasonably say that "the maintainer of bar didn't add the
correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but
judging by the number of "missing Breaks/Replaces" bug reports that have
to be opened by unstable users (sometimes me), it's a very easy mistake
to make.
One thing that's particularly tricky about this is that the move from
/ into /usr and the move from foo to bar might be 18 months apart if
they happen to occur at opposite ends of our stable release cycle. In
particular, if the move from / into /usr is done as soon as the Debian 13
cycle opens, we cannot predict whether the packages that have undergone
that move will also need to undergo a package split/merge at some point
in the following 18 months (but it's reasonable to assume that at least
some of them will).
smcv
Reply to: