* Josh Triplett <j...@joshtriplett.org> schrieb: > 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.
Actualy, I'm opposed to putting default config files somewhere else from operating perspective. Having the initial configs in /etc is much easier when installing and then reconfiguring a package (it's already obvious where to look for the config file, and with proper comments you easily know what you might have to adapt). Not sure how Debian handles this, but Gentoo has a wonderful tool called etc-update for managing config file updates. > 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. Which packages ship files in /var ? > /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. Are there any packages installing something in /home, /tmp, /lost+found or /media ? > 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. I personally haven't seen an installation where /usr is actually shared between separate hosts, I don't have a real position on that. But: /usr is meant for things that are not needed by an minimal bootup, eg. singleuser or fundamental networking only (ip-stack + sshd), so they can be splitted to separate media, eg. for emergency cases. For completey fresh installations, there are probably better ways for providing remote recovery (eg. large hosters have rescue boot), maybe even using containers etc. But the big problem are the uncountable existing systems which might become troublemakers with that change. We need practical and reliable migration strategies first. In the end, I'm curious if it's really worth all of this. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- 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/20111230052144.ga25...@mailgate.onlinehome-server.info
