Bug#914897: debating the wrong thing
On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> Gunnar Wolf writes:
> > Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
> >> (...)
> >> So, let's enumerate possible outcomes:
> >>
> >> 1. no usrmerge
> >> 1a. no moves at all (no effort needed!)
> >> 1b. moves via some dh_usrmove tool, until /bin is empty
> >> 2. supporting both merged-usr and unmerged-usr
> >> 3. mandatory usrmerge
> >> 3a. by Bullseye
> >> 3b. by Buster
> >>
> >> Unless the TC decides for 2., all this work will be a pure waste of yours
> >> and maintainers' time.
> >
> > ...One thing I fear here, that's also not being clearly debated AFAICT
> > (although the "urgency" of this report points in the right direction)
> > is that if the TC decides towards anything but 2 or 3b, we will have a
> > hard time reaching and following through the freeze targets proposed
> > by the Release Team. Which is something we don't want.
>
> I don't think this list is good as (2) doesn't say anything about the
> question asked originally (the default) and (3a) doesn't say anything
> about what happens for Buster.
>
> Currently implemented is (2) + default to merged-/usr for new
> installations.
Good point -- so there's:
2. supporting both merged-usr and unmerged-usr
2a. default to merged
2b. default to unmerged
I believe the difference between those is less than between suboptions of 1
and 3, but then, as an opponent of 2 as a whole I'm biased.
> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
> systems would no longer be supported.
They'd be exactly as supported as they are today. Ie -- they'll continue to
work, and continue to be useless for building packages without a clean
chroot.
> In this case someone would have to write a unusrmerge program to convert
> systems with merged-/usr to systems with unmerged-/usr.
> Such a program doesn't exist yet and is probably more complicated than
> usrmerge: for example how would it know that a /sbin/iptables ->
> /usr/sbin/iptables symlink would have to be created when unmerging the
> system? Moving files from /usr to / is also more likely to run out of
> disk space (if separate partitions are used for /usr and /).
>
> I'm not sure how long it would take to get this right and so agree that
> (2) or (3b) or (3a-with-support-in-buster) are reasonable choices.
unusrmerge would still be still far less work than continuing with 2. Yet I
don't understand your claim why 1 or 3a w/o usrmerge-in-buster would cause
any problems. In fact, they require no work at all (in Buster's cycle)
beyond an upload of debootstrap.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄⠀⠀⠀⠀ to the city of his birth to die.
Reply to: