On Wed, Sep 28, 2022, at 1:40 PM, Helmut Grohne wrote: > 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.
*nod* I don't think we need to worry about this when there's a declared package-level conflict. > Depends on whether you consider that one-liner above tooling I guess. Good enough for now, probably -- it would be nice to have some automation searching for such overlaps in packages that *don't* declare Conflicts, and filing bugs, but I won't call that a blocker. > Do you see any other issues? Not at present, but I'm not the person you should be asking! The only person who could possibly say "yeah, the rules in place are sufficient to prevent problems post-bookworm until the bugs are actually fixed", with the level of confidence we need before proceeding with this transition, is ... the dpkg maintainer. zw
