Red Hat Bugzilla – Bug 122713
%scriptlets fail when /usr/share is mounted read-only
Last modified: 2008-05-06 19:58:49 EDT
Description of problem:
| # rpm -Uvh cup-v10k-13.i386.rpm
| 1:cup ########################################### [100%]
| rm: cannot remove `/usr/share/java/java_cup.jar': Read-only file system
| ln: `/usr/share/java/java_cup.jar': File exists
| error: %post(cup-v10k-13) scriptlet failed, exit status 1
| # rpm -q cup
| # rpm --showrc | grep netsha
| -14: _netsharedpath ...:/usr/share:...
| # cat /proc/mounts | grep /usr/share
| morden:/usr/share /usr/share nfs ro,...
See discussion at bug #51193 also.
Version-Release number of selected component (if applicable):
*** Bug 122714 has been marked as a duplicate of this bug. ***
*** Bug 122717 has been marked as a duplicate of this bug. ***
Note to self: how does rpm remove the files from a read-only filesystem?
rpm does not have to remove these files: this /usr/share filesystem is
shared between several hosts and exactly one host is responsible for
installing software there.
So, this host creates and removes the files there. The other ones just
can assume the files there.
Ok, so I need to make the scriptlets fail gracefully at uninstall time...
Still with current java packages (and with %post scriptlet also).
I do not understand why the 'javaconfig' magic in the scriptlets is
needed overall. Creating new files in %scriptlets conflicts somehow
with the idea behind rpm and you can not use them in a way like:
| Requires: /usr/bin/xsltp
as rpm does not know about this file
Why do you not execute 'javaconfig' in the %install script and ship
the generated symlinks as ordinary %files?
*** Bug 142103 has been marked as a duplicate of this bug. ***
has a better than even chance of Doing The Right Thing (looking first in Basenames,
then in Providenames, indices) with the Provides: above.
Unfortunately, that also means that all the python script kiddies would need to
change their code to do that too. I suggested hiding the
Look in Basenames, then in Providename.
step as part of the rpmdbInitIterator() bindings, the response from the python
script kiddies was a loud and resounding
But that's off topic. Testing for RDONLY in scriptlets is one approach, using the
existing %netsharedpath mechanism within rpm is another approach, both of
which can be done without changing rpm.
Adding a secret sauce semantic like
Skip file paths on RDONLY media automagically.
could be attempted within rpmlib, it's not like the install is ever gonna
succeed. That was proposed and rejected because rpm users tend not
to be able to adjust their expectations to understand implicit semantics.
The other approach to the problem in rpmlib, automagically remounting RDONLY partitions RW,
installing, and then remounting RDONLY, is likely to be a support nightmare.
If up to me, I'd say "Fix the packaging." first, then lean towards the "Skip file install if RDONLY."
> The other approach to the problem in rpmlib, automagically remounting RDONLY
> installing, and then remounting RDONLY, is likely to be a support nightmare.
Yes Jeff, this will be a nightmare. You will have to implement the most-recent
attacks for your favorite ssh/ssl/httpd/... security hole, so that you can
temporarly rewrite the
| ...something... (ro,...)
part in /etc/exports of the NFS server. ;)
It doesn't look feasible to fix this before FC5.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: