Bug 122713
| Summary: | %scriptlets fail when /usr/share is mounted read-only | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Enrico Scholz <rh-bugzilla> |
| Component: | cup | Assignee: | Gary Benson <gbenson> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | triage, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | bzcl34nup | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-05-06 23:58:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 150223 | ||
|
Description
Enrico Scholz
2004-05-07 12:12:42 UTC
*** 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. *** 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."
> 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. ;) 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: 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. 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 |