Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
Hi Zack,
On Wed, Sep 28, 2022 at 12:29:19PM -0400, Zack Weinberg wrote:
> I thought about this a bunch yesterday evening and I believe I see a
> concrete scenario that can cause problems but is not covered by the
> moratorium: Suppose there exist two packages, one of which ships
> /bin/foo, and the other ships /usr/bin/foo. On a non-merged system,
> these packages can coexist. On a merged system, they have a file
> conflict that dpkg will not detect.
$ ssh delfin.debian.org sqlite3 /srv/dedup.debian.org/database/dedup.sqlite3 '"'"SELECT * FROM content AS ca JOIN content AS cb ON ca.filename = './usr' || substr(cb.filename, 2) WHERE cb.filename NOT LIKE './usr/%';"'"'
166447797|96615|./usr/bin/systemctl|201531|221889683|4004|./bin/systemctl|1173136
210029518|32365|./usr/sbin/update-service|2917|223295080|31077|./sbin/update-service|4573
$
So we have systemctl vs systemd and daemontools-run vs runit, both of
which declare Conflicts.
> So questions for you and everyone else reading this:
>
> 1. Is there already a rule (or multiple rules) somewhere that forbids
> the existence of pairs of packages where one ships /X/Y and the
> other ships /usr/X/Y, where X is a directory on non-merged-/usr
> systems and a symlink on merged-/usr systems, and Y is any name?
I think Marco et al have been filing bugs about these kind of issues and
NMUing the remainders a very long time ago way before debootstrap
defaulted to merged /usr.
> 2. Does Debian already have tooling that can *find* pairs of such
> packages? (This is a fully independent question from 1. If
> there's a rule but no automation to enforce it then we don't *know*
> nobody's breaking the rule. If there is no rule then, before we
> consider adding such a rule, we need to know whether any packages
> exist that break it.)
Depends on whether you consider that one-liner above tooling I guess.
Do you see any other issues?
Helmut
Reply to: