On Mon, 22 May 2023 at 22:13, Étienne Mollier <emoll...@debian.org> wrote: > > Luca Boccassi, on 2023-05-22: > > On Mon, 22 May 2023 at 20:34, Sam Hartman <hartm...@debian.org> wrote: > > > > > > >>>>> "Luca" == Luca Boccassi <bl...@debian.org> writes: > > > > > > Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman <hartm...@debian.org> > > > wrote: > > > >> > > > >> >>>>> "Luca" == Luca Boccassi <bl...@debian.org> writes: > > > >> > > > Luca> Hello Release Team, If we were to do a MBF against packages > > > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > > > Luca> /lib*, would you accept the consequent mass unblock request? > > > Luca> I am asking beforehand as there's no point in going through > > > Luca> the effort if you don't, the advantage is only if we can sort > > > Luca> it before Bookworm ships, and the bugs would become invalid > > > Luca> and be closed as soon as it does as per moratorium otherwise. > > > >> > > > >> This sounds like a really bad idea. While technically this is > > > >> consistent with the TC's advice, what you are proposing to do > > > >> increases the chance that you're going to trigger the dpkg > > > >> disappearing file bug. > > > >> > > > >> Consider: > > > >> > > > >> * User installs version from testing with file in /bin * > > > >> Maintainer quickly moves the file to /usr/bin per your MBF * > > > >> Bookworm releases; user does not upgrade at this point * Package > > > >> reorganization; file moves between packages * User upgrades; file > > > >> disappears > > > > > > Luca> What "package reorganization" would that be? Are you aware of > > > Luca> any such thing happening in the next couple of weeks before > > > Luca> release? > > > > > > Who said anything about next couple of weeks. This affects testing and > > > unstable users *after the release*. It is my experience of Debian that > > > outside of freezes package reorganizations happen regularly. > > > > So what you are worried is the combination of a testing installation > > from~one year ago, that is otherwise never touched for say another > > year, and also that has one of those 23 packages installed in the old > > version, and also that same package of those 23 gets rearranged? That > > seems vanishingly unlikely, > > Against all odds, I can see very well this happening, so I guess > it shouldn't hurt to flag somehow packages having had to proceed > per the MBF. Big "warning" comments at a few strategic points > in d/control and install files might probably be a bare minimum, > so team fellows or future self won't trip on the carpet when > tempted to reorganize files.
In case such an update is a supported use case, then yes, adding a comment to the install file where the change is applied would make perfect sense, as that's where it would be hypothetically removed from in that example. Kind regards, Luca Boccassi