On 02/01/2016 23:39, Arnt Karlsen wrote:
> On Sat, 02 Jan 2016 05:50:15 -0500, Mitt wrote in message
> <jtiMA6Mbvw7CTU1emAUqy0_CPd1d4pjRvXxt0zby0A2XXS-dLes3dkdkEfmNfz50xSao-vdE4A_lgWu0zEpSiA==@protonmail.ch>:
>
>> Not sure about poetteringisation (of how should this be spelled?)
>> but take a look at this link:
>> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>>
>> and this
>> https://fedoraproject.org/wiki/Features/UsrMove (see owners)
>>
>> and even this
>> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>>
>> Simplification? Heh.
>>
>> The same thing: why change something that has been working
>> (flawlessly?) for four decades.
>
> ..to subvert and scuttle the competition.

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