On 21/11/18 at 20:56, Hendrik Boom wrote:
> On Wed, Nov 21, 2018 at 05:24:24PM +0100, Alessandro Selli wrote:
>> On 21/11/18 at 16:59, KatolaZ wrote:
>>> On Wed, Nov 21, 2018 at 07:32:22AM -0800, Rick Moen wrote:
>>>> Quoting Roger Leigh (rleigh@???):
>>>>
>>>>> I've been following the discussion with interest.
>>>> For values of 'following' that equates to noting that the matter has
>>>> been discussed, but then ignoring its substance.
>>>>
>>> Dear Rick,
>>>
>>> you could have noticed that in essence Roger pointed to the merged-usr
>>> solution as not only impractical, but also risky and of doubtful
>>> usefulness.
>>
>>   So, you agree then that:
>>

> ...
> ...
>>  3. "you can't split the package database between separate systems"
>>     (whatever this means, who needs to split the package database and why?);
> This is about upgrades using the package manager.
> If there are two /'s

  Two roots?  Like when you have several systems booting on the local
disk but mounting some filesystems, among them /usr, from the same
shared partition/NFS server?


> sharing one single /usr, when you upgrade, one of the
> /'s will be upgraded consonant with the /usr, and the other will not be.
> How then to upgrade the other /? Its package database will no longer
> be in sync with its /usr.


  If I got you right, the problem would be that some systems would have
a /usr already updated by another system that performed the update
before it did.  This should not be a problem with security updates, the
/usr would just be updated several times, one for each system that uses
the same /usr.  A serious problem would arise with a major OS version
upgrade.  in this case, a single system should perform the full update
and the others should be put in sync offline.  Easier said that done, I
understand, still syncronization is a problem with any number of
independent systems that share something among them.

  You do have a point here, a merged / -> /usr would make upgrades
easier on clusters (who said Red Hat?), because it forces them to share
the whole, single filesystem.  But the point is that ease of management
of such a cluster is not a good reason to impose a filesystem design
change on everybody else.  For all their importance, clusters are a
corner case among the many uses GNU/Linux is deployed for; it is indeed
a good thing that they had the possibility of performing the merge, but
there is no reason desktop installations should be deprived of the
choice to not do the same.


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