Hi Roger, Could you please send your text below to debian-devel too? Here at Devuan most people are aware of the issues. Unfortunately many of the Debian developers/maintainers aren't :(
On Sun, 2016-01-03 at 13:25 +0000, Roger Leigh wrote: > > It's not something that nefarious. It's about inexperienced people > looking at historical practices/mistakes and trying to "correct" > them. > That said, you can't ever remove something as entrenched as /usr, at > least, not without widespread breakage. No one who cared about > compatibility would consider that. > > The *real* goal here is something rather simpler: having both / and > /usr > mounted in the initramfs. The primary reason for this is that there > are > genuine problems with stuff on / needed in early boot having library > dependencies located in /usr. Libraries were moved to / on a > case-by-case basis, but it's really just the tip of the > iceberg. E.g. > PAM modules needing openssl, datafiles from /usr/share, etc. It > becomes > a nightmare to coordinate and manage, particularly when you also have > to > consider third-party stuff out of your control. Simply ensuring that > /usr is available in the initramfs solves all these problems. The > requirements coming from systemd/freedesktop about this are > essentially > the same, but in a typically inflexible and our-way-only manner. The > actual problem here predates systemd by many years. > > Note that I wrote the patches which mount /usr in the initramfs in > addition to /. This gives all the primary benefits of the /usr merge > without actually changing anything. It means that from this point > on, > you can freely make use of programs, libraries and datafiles in /usr > during early boot. I.e. the only change is a guarantee of when > things > are available. The exception to this is that you can no longer boot > from a system with a split /usr unless you have an initramfs. > > > When you look at the /usr merge stuff which can follow on from this, > there are several steps one might take: > - having / and /usr on the same filesystem > - then symlink programs from /usr/bin to /bin (or vice versa) (and > lib etc.) > - or symlink the whole of /usr/bin to /bin (or vice versa) (and lib > etc.) > - or symlink /usr to / > > RedHat chose to move the whole of / to /usr, and symlink to it from > the > old locations. It's kind of backward. It was done since /usr was > often > bigger than /, so makes sense for upgrades where migrating the other > way > would fail. But as the long-term goal and for fresh installs, it's > not > really solving any real-world problem. Just having everything on a > single filesystem (or mounting everything in the initramfs) already > solved those. > > Historically, GNU/Hurd symlinked /usr to /. It would have been a > good > goal for Debian GNU/Linux. It needed an audit of potentially > conflicting files to ensure the package dependencies were OK, but > would > otherwise be doable simply by making /usr a symlink in base-files > (for > new installs). > > Whichever way you do the merge, hardcoded paths like /bin/sh and > /usr/bin/whatever are part of the platform. They will be required to > be > accessible using the old names indefinitely. So the actual *need* > for > the merge is moot. > > Regarding the comments people made about having separate / and /usr > filesystems. While it was common historically, there is little or no > practical benefit to doing so in 2016. Storage sizes make it > unnecessary for pretty much all practical scenarios. The two are > managed by dpkg as a coherent whole; they are logically inseparable. > They serve the same purpose. Do reconsider whether it's actually > necessary for you to do this, or whether it's merely habit. Some > historical practices continue to have value; others, including this > one, > do not. > > > Regards, > Roger > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
