[linux-lvm] Mandrake 8.1 and LVM

[Chad C. Walstrom]

On Fri, Nov 30, 2001 at 09:41:21PM +1300, Steve Wray wrote:
> > Reason #1:  Mount /usr as read-only.  There is only one reason why you
> 
> ONLY if you also have /usr/share (for one, there may be others) on writeable
> partitions!!!

Why would you want/need to have /usr/share writeable?  FHS 2.2 states:

        4.11  /usr/share : Architecture-independent data

        4.11.1  Purpose

        The /usr/share hierarchy is for all read-only architecture
        independent data files. [25]

        This hierarchy is intended to be shareable among all architecture
        platforms of a given OS; thus, for example, a site with i386,
        Alpha, and PPC platforms might maintain a single /usr/share
        directory that is centrally-mounted.  Note, however, that
        /usr/share is generally not intended to be shared by different
        OSes or by different releases of the same OS.

        Any program or package which contains or requires data that
        doesn't need to be modified should store that data in /usr/share
        (or /usr/local/share, if installed locally).  It is recommended
        that a subdirectory be used in /usr/share for this purpose.

        Game data stored in /usr/share/games must be purely static data.
        Any modifiable files, such as score files, game play logs, and so
        forth, should be placed in /var/games.

        ...

        Footnote: 
        25.  Much of this data originally lived in /usr  (man,  doc)  or
        /usr/lib (dict, terminfo, zoneinfo).

-- 
Chad Walstrom <chewie at wookimus.net>                 | a.k.a. ^chewie
http://www.wookimus.net/                            | s.k.a. gunnarr
Get my public key, ICQ#, etc. $(mailx -s 'get info' chewie at wookimus.net)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20011130/d25787a3/attachment.sig>