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 (rle...@codelibre.net): > >>>> > >>>>> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
