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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng