On 21/11/18 at 13:17, Roger Leigh wrote:
> Hi folks,
>
> I've been following the discussion with interest.


  No, you definitely have not followed it.  In fact you are disregarding
all the points that were expressed against the merge.


>   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


  Yes it does, and they were already listed:


1) mounting /usr with different mount options (like barrier, ro, nodev etc);

2) having /usr mounted over the network keeping / local;

3) having a /usr partition shared by several local installs that are
booted on different / filesystems;

4) having the smallest possible / filesystem to ease recovery of a
botched 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.  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.)


  This too was debated and rejected.  It doesn't matter if some idea
originated out of specific restraints or circumstances, of it it was a
bad idea at the time.  Time proved it to be a good filesystem layout,
and it's for this reason is has survived to this day.


>    Other systems, like the BSDs, have the effective split between base
> (/) and ports (/usr/local).  / and /usr are still effectively a
> managed whole containing the "base system".


  So what?  How does this imply that the possibility of not having a
"managed whole" in Linux is a bad idea?


>    With those points considered, merging / and /usr would make sense.


  Being those points baseless, the proposed merge lacks the sense it
needs to be forced upon everybody.


> Though equally, keeping the separation doesn't hurt *if they are on
> the same filesystem*.


  Most of the times the separation is needed just to have / and /usr
stay on different filesystems.  The merge would make this impossible.


>   If they are to be merged, then there are two possibilities: moving
> /usr to / or the contents of /* to /usr.
>
>    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,


  Please keep this misplaced worship of your sacred "managed whole" away
from *my* systems.

  Splitters are nor forcing they choices on others and their operations
do not adversely affect the possibility of merging whatever one wants. 
Mergers instead are keen at imposing their baseless sense of technical
perfection on everybody reducing the effective freedom of system
customization.


> and hiving off a static /usr rather than hiving off the variable
> changing content isn't really doing more than adding extra unnecessary
> complexity.


  "Unecessary" according to whom?  Once merged, several operations that
were possible with a split /usr are no longer possible, how is that a
simplification?  You are basically stating that having people stop
customizing key aspects of their OS layout and organization to force
everybody into the same mold is good because it simplifies matters. 
What would it simplify and to whom?  Taking freedom away can be regarded
as a form of simplification, I agree, but it's a sick simplification,
like banning all left-handed people out of society.


> 2) Moving the content to /usr doesn't preclude moving it to / later


  And keeping / splittable from /usr does not prevent anybody from
merging them, too.


>    RedHat/systemd have decided to move everything to /usr, and Debian
> have decided to copy this as they have for most systemd-dictated
> changes.  I'd prefer it to be the other way around; it's cleaner


[lots of drivel trashed]


> Lastly, regarding the comments about Devuan "disenfranchising" itself
> from Debian to not be "in the back seat".   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.


  The fact that Canonical decided to keep following Debian's
architectural design is pointless.  AFAIK this decision did not stem out
of the consideration that Canonical was unable to go it's own way, in
fact it did several times (even though with no much success, like when
they produced Ubuntu Touch aka Ubuntu Phone, Unity, Upstart and Mir). 
This myth is easy to dispel considering the large number of
distributions, even historical ones, that are completely independent
from any major one, that they were designed from scratch or that they
started off from some existing distribution: Slackware, Kali, Gentoo,
Void, Arch and so on.



--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE