On Wed, 21 Nov 2018 12:17:21 +0000
Roger Leigh <rle...@codelibre.net> wrote:
> Hi folks,
>
> I've been following the discussion with interest. It's certainly not
> a new discussion, since I remember debating it a good few years back,
> but there are still the same opinions and thoughts on the topic that
> I remember from back then.
>
> Some general points to consider:
>
> 1) A separate /usr serves no practical purpose on a Debian/Devuan
> system
>
> Historically, /usr was separately mountable, shareable over NFS.
> With a package manager like dpkg, / and /usr are an integrated,
> managed whole. Sharing over NFS is not practical since the managed
> files span both parts, and you can't split the package database
> between separate systems.
What I hear in the preceding paragraph is that dpkg considers /
and /usr a package deal (no pun intended), and so can't abide an NFS
mounted /usr. Telling people to merge / and /usr for this reason is
fixing the symptom and letting the root cause remain. That's usually
not a good idea, but perhaps in this case fixing dpkg would be too
difficult...
> Modern disk sizes make partitioning a
> separate /usr unnecessary and undesirable. (Both are of
> course /possible/, but there is precious little to gain by doing so.)
Well, *you* might not want a mounted /usr, and *I* certainly don't want
a mounted /usr, but we don't speak for every user in every context, and
we can't anticipate every context. So "serves no purpose" as a blanket
statement is false if we find one person using or wanting to use a
separate /usr on a De??an system.
I can imagine that somewhere there's a guy who gains speed by, boot
after boot, copying executables to /usr on a mounted RAM drive, and who
doesn't want to use an initramfs, who would be quite perturbed by the
merge.
[snip]
>
> The point about /usr being a good place for "static" content is a
> reasonable one. But for better or worse, / is "the system". It's
> still part of the managed whole, and hiving off a static /usr rather
That's not what I said upthread. What I said upthread is to continue to
have static programs in /sbin, sufficient to mount everything and to
troubleshoot if /usr fails to mount or something else goes wrong. As
far as /usr, its executables can and should use loadable libraries.
[snip]
> 2) Moving the content to /usr doesn't preclude moving it to / later
Huh?
> RedHat/systemd have decided to move everything to /usr, and
If you agree with me that the Linux landscape is no longer a
technocracy, then the preceding half sentence is a reason not to make
the move.
> Debian have decided to copy this as they have for most
> systemd-dictated changes.
This is no surprise. Today's Debian is nothing like 20th century or
early 21st century Debian. I already linked a few days ago to the
kangaroo court way they forced systemd through.
> I'd prefer it to be the other way around;
> it's cleaner and it's what we would choose given a clean slate.
The preceding sentence is true, I'd imagine. But like the original
systemd debate, it's not an either-or situation. A third alternative is
to not copy anything anywhere, but instead leave the
early-boot-necessary stuff in /sbin, where it can be accessed the
microsecond / is mounted, without the need for /usr to be mounted.
> However, when multiple filesystems are in use, /usr is often larger
> and this is potentially the safer move *for upgrades*.
And here again, for upgrades, the "make no change" solution would be
even safer.
[snip the instructions on how to do unification: I don't see
unification as a good thing]
[snip the upgrade compatibility section because I'm not knowledgeable
enough to comment or critique, and because whenever faced with a whole
number version number increase, I wipe and reinstall]
>
> 4) None of it actually matters
^^^^^^^^^^^^^^^^^^^^^^^^^^^
For most people.
>
> The whole discussion is based on the premise that they are
> separate. In practice, the vast majority of us have them on the same
> filesystem, given that there is no practical purpose to the
> separation as in (1) above.
"vast majority of us". Not a distro on this earth has avoided
disenfranchising a few for perceived ease for the many. But unlike
Ubuntu and Mint, pre-2014 Debian and post-2014 Devuan have
traditionally opted for maximum user configurability.
[snip containers and BSD]
>
> Like a lot of systemd-driven changes, unifying these filesystems is
> technically possible, slightly desirable, but at a huge practical
> cost.
Couldn't have said it better myself.
> The main costs are the severe risks taken to migrate essential
> system files and rearrange the root filesystem during an upgrade.
> Given that from the user's and sysadmin's point of view, the system
> behaves the same both before and after the upgrade, they are being
> required to undertake a large risk for *almost zero* practical
> benefit.
I'd speculate the main costs are breaking running systems, and forcing
people with systems adapted to their way of doing things to change
their way of doing things, or adopt a workaround kludge.
> Personally, I would argue this should only be done for
> fresh installations.
I'd argue it shouldn't be done at all, but the idea of *fresh installs*
enabling one to opt in to the merge is OK.
> I don't think the potential for
> near-irreparable damage to running systems is acceptable. Depending
> upon the configuration, there's a risk of the system no longer being
> bootable, of the system being in a corrupt state if the migration
> fails due to the /usr filesystem not having enough space to migrate
> the files, or dpkg not being able to revert or complete the operation
> if interrupted.
Won't get any argument from me pertaining to your preceding paragraph.
>
>
> Lastly, regarding the comments about Devuan "disenfranchising" itself
> from Debian to not be "in the back seat".
Huh?
> I take the point, but the
> practical reality is that Debian is so huge not even a company with
> many dozens of employees like Canonical could manage that feat. It's
> simply impractical. If Devuan continues as a derivative by
> maintaining a modified set of core packages to meet specific goals,
> it would seem that it's meeting it's core objectives, and that's no
> bad thing. It's realistic, and manageable.
I don't understand the preceding paragraph, but as long as Devuan keeps
out the Poettering/Redhat/Freedesktop poison pills, I'm happy.
Unfortunately, because I don't think this is a technocracy and I don't
think systemd was created for technical reasons, I think keeping out
the poison pills will *eventually* mean Devuan doesn't use Debian in
any way.
S U M M A R Y :
You mention:
===========================================
> Like a lot of systemd-driven changes, unifying these filesystems is
> technically possible, slightly desirable, but at a huge practical
> cost.
===========================================
And you mention, pertaining only to upgrades, but I contend less but
still materially to fresh installs:
===========================================
> I don't think the potential for
> near-irreparable damage to running systems is acceptable. Depending
> upon the configuration, there's a risk of the system no longer being
> bootable, of the system being in a corrupt state if the migration
> fails due to the /usr filesystem not having enough space to migrate
> the files, or dpkg not being able to revert or complete the operation
> if interrupted.
===========================================
* Technically possible
* Slightly desirable
* Huge practical cost
* Possible near-irreparable damage to running systems
. Possible no-boot
. Possible corrupt state
If a salesman showed you a car technically possible but slightly
desireable, with a huge practical cost, possible near-irreparable
damage, who here would write him a check?
I'm very glad the current plan is to make this "merge" opt-in only for
fresh new installs.
SteveT
Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
