On Mon, Dec 26, 2011 at 05:23:56PM -0800, Steve Langasek wrote: > On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote: > > Not quite. Redhat and others want to make this change (moving binaries > > and libraries from / into /usr) not just for ease of maintenance (though > > that makes sense too) but for several rather interesting reasons. It > > would consolidate almost everything managed by the package manager under > > /usr. > > That's not interesting at all.
Sorry you don't find it interesting. Other people do. In any case, I primarily wanted to explain the rationale, which went beyond the "upstream being difficult" repeated by others in the thread. > > Configuration would live in /etc (with templates possibly provided by > > packages, though more and more packages follow the "override files in /usr > > with files in /etc" approach and ship no /etc configuration by default). > > That's the FHS and has nothing to do with moving things. Well aware of that; just trying to fill in the full picture of how the top-level directories would look after a move from / to /usr. Also, the FHS says nothing about the current approach of overriding files in /usr with files in /etc, which allows packages to stop shipping configuration files in /etc that just consist of the default settings. > > /var includes bits that change, which should not normally include > > package-managed bits. > > That's also in the FHS. Again, well aware of that; just trying to fill in the full picture of how the top-level directories would look after a move from / to /usr. Also, nothing in the FHS states that packages shouldn't ship files in /var. > > This would make /usr easy to snapshot, easy to exclude from backups, > > easy to share between systems, easy to mark read-only (mount --bind -o > > ro /usr /usr) and various other fun possibilities. > > I don't think /bin, /sbin, and /lib are seriously blocking anyone from doing > any of these things today. /bin, /sbin, /lib, /lib32, /lib64, and package-managed files in /var and /etc make these things significantly less convenient. More to the point, all of those directories (as well as /usr) exist as top-level directories right next to /home, /tmp, /lost+found, /media, and others which often require different treatment. Right now, all of the activities I mentioned require careful inclusion/exclusion rules: either "include /, except exclude a pile of top-level directories" or "include a pile of explicitly listed top-level directories". Personally, I'd find it rather convenient to have all of that consolidated in /usr. So would the upstreams of various packages, hence this thread. > Indeed, people have consistently argued in this thread that /usr shared over > NFS is not a useful thing to try to do these days, and there's nothing > about adding /bin, /sbin, and /lib to /usr that changes these arguments. People have consistently argued that sharing /usr makes no sense without also sharing all the other package-managed bits that live outside /usr, such as /bin, /sbin, /lib, /lib32, /lib64, and so on. However, consolidating all the package-managed bits in /usr would make it entirely sensible to share /usr as a single consistent pile of packaged bits. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111230013640.GA4475@leaf