Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 22:13, Étienne Mollier <emollier@debian.org> wrote:
>
> Luca Boccassi, on 2023-05-22:
> > On Mon, 22 May 2023 at 20:34, Sam Hartman <hartmans@debian.org> wrote:
> > >
> > > >>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:
> > >
> > > Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman <hartmans@debian.org> wrote:
> > > >>
> > > >> >>>>> "Luca" == Luca Boccassi <bluca@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
Reply to: