Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 122713 - %scriptlets fail when /usr/share is mounted read-only
Summary: %scriptlets fail when /usr/share is mounted read-only
Alias: None
Product: Fedora
Classification: Fedora
Component: cup
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Gary Benson
QA Contact:
Whiteboard: bzcl34nup
: 122714 122717 142103 (view as bug list)
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
Reported: 2004-05-07 12:12 UTC by Enrico Scholz
Modified: 2008-05-06 23:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-06 23:58:49 UTC

Attachments (Terms of Use)

Description Enrico Scholz 2004-05-07 12:12:42 UTC
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
| cup-v10k-12
| cup-v10k-13
| # 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):


Comment 1 Gary Benson 2004-05-07 16:47:14 UTC
*** Bug 122714 has been marked as a duplicate of this bug. ***

Comment 2 Gary Benson 2004-05-07 16:47:23 UTC
*** Bug 122717 has been marked as a duplicate of this bug. ***

Comment 3 Gary Benson 2004-05-07 16:49:15 UTC
Note to self: how does rpm remove the files from a read-only filesystem?

Comment 4 Enrico Scholz 2004-05-07 16:59:09 UTC
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.

Comment 5 Gary Benson 2004-05-10 11:09:32 UTC
Ok, so I need to make the scriptlets fail gracefully at uninstall time...

Comment 6 Enrico Scholz 2004-06-27 17:13:11 UTC
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?

Comment 7 Gary Benson 2005-06-03 09:15:51 UTC
*** Bug 142103 has been marked as a duplicate of this bug. ***

Comment 9 Jeff Johnson 2005-07-12 16:02:07 UTC
FWIW, adding
    Provides: /usr/bin/xsltp
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
   No way!

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."

Comment 10 Enrico Scholz 2005-07-12 17:57:10 UTC
> 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.

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. ;)

Comment 11 Warren Togami 2006-03-06 15:33:51 UTC
It doesn't look feasible to fix this before FC5.

Comment 13 Bug Zapper 2008-04-03 15:34:26 UTC
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: to ensure this
doesn't happen again.

Comment 14 Bug Zapper 2008-05-06 23:58:47 UTC
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:

Note You need to log in before you can comment on or make changes to this bug.