:: Re: [DNG] /usr to merge or not to m…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Hendrik Boom
Fecha:  
A: dng
Asunto: Re: [DNG] /usr to merge or not to merge... that is the question
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