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.