Re: DEP 17: Improve support for directory aliasing in dpkg
On Sat, 22 Apr 2023 at 11:41, Simon McVittie <smcv@debian.org> wrote:
>
> 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).
We already have piuparts tests detecting files moving, it should be
easy enough to extend that to check that the appropriate
Breaks/Replaces have been added. Correct me if I'm wrong, but I
believe it's already against policy to do this without
Breaks/Replaces, so it's not a use case that we need to support, no?
If someone does that by mistake, the package will not migrate to
testing.
Kind regards,
Luca Boccassi
Reply to: