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