Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst <wouter@debian.org> wrote:
>
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.GA31273@espresso.pseudorandom.co.uk
Thanks; somehow I missed that, sorry.
> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.
The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.
It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.
> Even ignoring that, it would not bring any improvement over the current
> plan:
This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).
Changing this through a policy change, as we've always done, would not
have those problems:
- Maintainers are expected to move their own package to merged-/usr, so
they would be aware of issues that might ensue and would be able to
deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
the same time; instead, we'll be gradually moving towards a
merged-/usr situation.
- We don't end up with packages' files being moved from under them.
> even if your idea were executed perfectly and quickly then the
> conversion program would still be in the same exact situation as it is
> now:
Yes, obviously, that's the whole point.
[...]
> So this would make the transition unacceptably slow while providing no
> benefit at all,
I don't agree with both these statements.
> but it would also cost a huge amount of work to change many packages.
Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Reply to: