Bug 1052997 - Unable to install scl-utils on system with read-only opt directory
Summary: Unable to install scl-utils on system with read-only opt directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: scl-utils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Zeleny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1053004 (view as bug list)
Depends On:
Blocks: 1053004
TreeView+ depends on / blocked
 
Reported: 2014-01-14 14:50 UTC by David Jones
Modified: 2015-01-30 04:44 UTC (History)
4 users (show)

Fixed In Version: scl-utils-2.0.1-2.fc21
Clone Of:
: 1053004 (view as bug list)
Environment:
Last Closed: 2015-01-30 04:28:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Jones 2014-01-14 14:50:44 UTC
Description of problem:
During update or installation, scl-utils attempts to create the directory /opt/rh. In our environment, we mount a read-only NFS export on /opt, so the update fails. 

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Attnempt to install or update scl-utils
2.
3.

Actual results:
yum update fails

Expected results:
yum update succeeds, or a clearer error message.

Additional info:
I was trying to update a newly installed system, which apparently had SCL installed by default. It took awhile to figure out why "yum update" was failing, because the error message wasn't very clear on what the problem was: "error: unpacking of archive failed on file /opt/rh: cpio: mkdir". Trying to install manually with rpm, gave more information. 

We're not currently using scl, but it's foreseeable that we could. The main issue here is the system update failing. it would be better if scl didn't try to create /opt/rh during install. Having a package from the standard repo write to /opt is unexpected behavior. It would be better, I think, if scl doesn't create /opt/rh, until it's actually used. After all, scl_prefix is configurable, so it ought to be up to the developer to create the directory where he/she wants it.

From a system admin perspective, it's time consuming for the admin to have to figure out why a system update is failing because of a package he/she isn't using, and may not know what it is. I'm not sure why SCL is installed on our systems. It may have come in with "Developer Tools."

Comment 2 Jan Zeleny 2014-01-15 08:02:34 UTC
*** Bug 1053004 has been marked as a duplicate of this bug. ***

Comment 4 Jan Zeleny 2014-01-20 09:30:23 UTC
I will take a look at this but it's going to have a low priority. The package has always been this way and the behavior is kinda expected. Before I remove the directory, I need to check that it won't break anything.

That being said, I wonder how the package got to your system in the first place, as rpm will try to create the directory during installation and it shouldn't install the package if /opt is not writable. Is it possible by any chance that the /opt was writable during the installation?

Also note that while the prefix directory is configurable, that only applies to the collections you build yourself, all Red Hat collections are and will be in /opt/rh in the foreseeable future.

Comment 5 David Jones 2014-01-24 23:36:47 UTC
Yes. The NFS mounts were added after initial install. My main concern is that the package was installed without being specified, as part of the base system. I didn't even know what it was for, at first. it took me a while to figure out why the update was failing.

It's not typical for standard packages to use the /opt directory. In all of my past experience, that's been reserved for 3rd party sofware. That's why we use /opt for our read-only NFS share, with all of our third party stuff on it.

Our group of developers supports a major RHEL consumer, and we don't really have a say in how these things are set up. We're just mirroring their systems. So I'm surprised this hasn't come up before.

Comment 6 Jan Zeleny 2014-04-10 08:02:51 UTC
Moving to Fedora, this has to be resolved upstream first ...

Comment 7 Jan Zeleny 2014-07-18 15:32:33 UTC
Upstream ticket:
https://fedorahosted.org/SoftwareCollections/ticket/27

Comment 8 Fedora Update System 2015-01-21 08:26:50 UTC
scl-utils-2.0.1-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/scl-utils-2.0.1-1.fc21

Comment 9 Fedora Update System 2015-01-21 08:27:11 UTC
scl-utils-2.0.1-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/scl-utils-2.0.1-1.fc20

Comment 10 Fedora Update System 2015-01-21 23:04:35 UTC
Package scl-utils-2.0.1-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing scl-utils-2.0.1-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-1006/scl-utils-2.0.1-2.fc21
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2015-01-30 04:28:37 UTC
scl-utils-2.0.1-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2015-01-30 04:44:09 UTC
scl-utils-2.0.1-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


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