Adam Borowski writes: > On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote: > 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,
Yes. > and continue to be useless for building packages without a clean > chroot. Oh? What makes you think so? You are free to correct my earlier estimate about the number of problems. So long I'll assume I'm not totally wrong. If I'm wrong by a factor of 3, then 99% of the packages will just build fine. And fixing any problem is in most cases straightforward. >> 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. Why do you think so? Trivial patches for the remaining few packages seem easier. > 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. Unless someone builds a package in an already existing install... If not being able to build packages in existing installations is not a problem, I'm even less sure what the problem with merged-/usr by default is supposed to be? Ansgar