Re: DEP 17: Improve support for directory aliasing in dpkg
On Sun, 7 May 2023 at 00:44, Sean Whitton <spwhitton@spwhitton.name> wrote:
>
> Hello,
>
> On Sat 06 May 2023 at 09:47PM +01, Luca Boccassi wrote:
>
> > On Sat, 6 May 2023 at 19:51, Helmut Grohne <helmut@subdivi.de> wrote:
> >>
> >> > - the moratorium on moving files from bin/ sbin/ lib/ _and_ to other
> >> > packages at the same time is maintained from bookworm till trixie, and
> >> > will lifted after trixie ships, and applies implicitly to all the
> >> > ~2000 binary pkgs that are affected by the above
> >>
> >> While the CTTE placed the moratorium until the release of bookworm, the
> >> release team extended it beyond, see
> >> https://lists.debian.org/E1oCdQk-0005ge-Nr@respighi.debian.org. So you
> >> need explicit agreement from the release team on your plan. Failing
> >> that, any package that has been forcefully moved is immediately
> >> rc-buggy due to failing a release team requirement.
> >
> > Of course the release team needs to be on board, no questions about
> > that. But given the idea is to maintain their decision exactly as it
> > stands I wouldn't imagine it would be an issue? Once again, the
> > moratorium is explicitly about moving between locations _and_
> > packages, in combination, not either/or. From that same email you
> > linked:
> >
> > "Files moving their canonical location between / and /usr (details in
> > [1]) *and* from one binary package to another binary package within
> > one release cycle remain an RC issue unless dpkg supports it."
> >
> > I'm proposing to keep this in place as a general rule, with the new
> > escape hatch that you devised as the only addition.
>
> Actually, the morotorium is not explicitly only about moving between
> both locations and packages. Firstly, the TC's morotorium does not have
> the qualification, restricting *any* movements in data.tar.*:
>
> The Technical Committee recommends that during the Debian 12
> development cycle, the maintainers of individual packages should not
> proactively move files from the root filesystem to the corresponding
> locations in /usr in the data.tar.* of packages. Files that were in
> /usr in the Debian 11 release should remain in /usr, while files
> that were in /bin, /lib* or /sbin in the Debian 11 release should
> remain in those directories. If files were moved from /bin, /lib*
> or /sbin into /usr since the Debian 11 release, they should be moved
> back to their Debian 11 locations.
>
> Then secondly, the RT's message is ambiguous, because it says both that
> they want the /TC's/ morotorium to remain in place, and also that files
> moving between both locations and packages is an RC issue.
>
> Until the RT's position is clarified, I think we should treat the
> broader prohibition as what they require. The TC are going to discuss
> this issue at our meeting on Tuesday, and one possible outcome is that
> we reissue our version of the broader prohibition.
Sure, this is in the context of the ongoing discussion in the TC about
revising their side of the advice. Also, we shouldn't lose sight of
the reason why this was issued in the first place: it is designed to
stop a problem from happening, and that problem can only happen when
both conditions are true. I can't read minds obviously, but I imagine
that's the reason the RT advice was worded as it was.
> Stepping back:
>
> I am far from being an expert on the details of merged-/usr. But one
> thing I've noticed is that among the people who have spent the most time
> looking into it, the majority think that simple fixes are not going to
> be sufficient. Only a few people who have spent a lot of time on it
> still think that the fixes that are required are relatively simple ones.
>
> If the former group are wrong then the transition takes longer than it
> needs to, but we don't lose any confidence in the state of our users'
> installations.
>
> If the latter group are wrong then we'll probably end up with a longer
> transition anyway, and a worse situation for both our maintainers and
> our users. And it's within one of the areas of Debian that we're most
> proud of -- completely smooth upgrades between stable releases.
>
> So, I think we should assume the people who are more worried are right,
> for the time being. We lose little in doing so.
Pondering about things is all well and good, however, I think the
'worry' needs to be realistic (eg: a conflict due to /bin/foo and
/usr/bin/foo both existing is not something that needs to cause any
worrying, as it is already disallowed by policy and unsupported), and
congruent with usual practices that are applied for all other changes
and processes. IE, the appropriate weighting should be given to
potential problems spotted.
Kind regards,
Luca Boccassi
Reply to: