[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: from / to /usr/: a summary



* Josh Triplett <josh@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: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


Reply to: