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
