Bug 122713 - %scriptlets fail when /usr/share is mounted read-only
%scriptlets fail when /usr/share is mounted read-only
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: cup (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gary Benson
bzcl34nup
:
: 122714 122717 142103 (view as bug list)
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2004-05-07 08:12 EDT by Enrico Scholz
Modified: 2008-05-06 19:58 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 19:58:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2004-05-07 08:12:42 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
| 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):

cup-v10k-13
Comment 1 Gary Benson 2004-05-07 12:47:14 EDT
*** Bug 122714 has been marked as a duplicate of this bug. ***
Comment 2 Gary Benson 2004-05-07 12:47:23 EDT
*** Bug 122717 has been marked as a duplicate of this bug. ***
Comment 3 Gary Benson 2004-05-07 12:49:15 EDT
Note to self: how does rpm remove the files from a read-only filesystem?
Comment 4 Enrico Scholz 2004-05-07 12:59:09 EDT
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 07:09:32 EDT
Ok, so I need to make the scriptlets fail gracefully at uninstall time...
Comment 6 Enrico Scholz 2004-06-27 13:13:11 EDT
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 05:15:51 EDT
*** Bug 142103 has been marked as a duplicate of this bug. ***
Comment 9 Jeff Johnson 2005-07-12 12:02:07 EDT
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 13:57:10 EDT
> 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 10:33:51 EST
It doesn't look feasible to fix this before FC5.
Comment 13 Bug Zapper 2008-04-03 11:34:26 EDT
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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 14 Bug Zapper 2008-05-06 19:58:47 EDT
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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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