On Thu, Jun 20, 2002 at 05:58:39PM +0400, Borsenkow Andrej wrote:
> 
> It looks like in this discussion two significantly different things are
> mixed up
> 
> 1. read-only /usr during daily operation.
> 
> Currently Mandrake does not allow it because some data that are 1)
> volatile - i.e. can be changed during normal operations and 2)
> system-specific are placed into /usr. It makes it very hard to both
> share /usr and mount /usr read-only (even if your /usr is not shared)
> but fixing it is relatively "trivial" (even if possibly tedious and time
> consuming).

Right on all counts!

> 2. installation/update of such a system
> 
> This is entirely different problem that depends if your /usr is local or
> shared. For local there is no problem - remount read-write, update,
> remount back.

Not very easy if any processes running have /usr as their cwd or have
files open in /usr.  I don't think it is seriously feasible to run
/usr ro most of the time and then switch to rw for updates.  Not
without a few reboots in between.

> For shared there is currently absolutely no provision. It
> is not enough to just update rpmdb or fake scripts because package may
> install itself both into /usr and into any other place in file system.
> So you need _rpm_ support with something like
> 
> rpm -U --with-shared-usr

Actually, rpm mostly does already Andrej.  "--excludepath /usr"
accomplishes this.  Scriptlets need to be aware of this option (if
possible) or be aware of /usr being mounted remotely when they try to
do anything that would require writing /usr.

> and rpm would skip adding files to /usr (but should obviously check and
> compare and warn if files are different).

Yeah, that last part I mentioned in my last e-mail.  That is gravy for
me.  If it does it, awesome.  If not, no biggie.

> And even this is not enough
> because you have to modify every script to be shared-/usr aware, you
> can't just skip execution of scripts.

Right!

> I do not even dare to think about what can of worms it is. If anybody
> has some references to successful projects I would be very interested to
> look at them.

Actually modifying the scripts would be more tedious than anything.  A
series of Cooker updates over a full release cycle (one version to the
next) would probably catch almost all of them.  Especially in times of
rebuilding the entire distro to go to gcc 3.1 for instance.

.

-- 
Brian J. Murrell

Attachment: msg66341/pgp00000.pgp
Description: PGP signature

Reply via email to