On Thu, Nov 22, 2018 at 04:12:23AM +0100, Alessandro Selli wrote:
> 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?
Yes, exactly. I'm trying to explain just what is problematic.
>
>
> > 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.
Exactly.
>
> 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.
-- hendrik
::
Re: [DNG] /usr to merge or not to m…
