Bug 1066665 - scl-utils: move statefiles and conf files to writable and non-shared locations
Summary: scl-utils: move statefiles and conf files to writable and non-shared locations
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:
Depends On:
Blocks: 1168682
TreeView+ depends on / blocked
 
Reported: 2014-02-18 20:45 UTC by Toshio Ernie Kuratomi
Modified: 2015-01-03 19:10 UTC (History)
3 users (show)

Fixed In Version: scl-utils-20140815-4.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-03 19:09:02 UTC


Attachments (Terms of Use)
Changes to the rpm macros that define the filesystem paths for confdirs and statedirs (863 bytes, patch)
2014-02-18 20:46 UTC, Toshio Ernie Kuratomi
no flags Details | Diff
Changes to the rpm macros that assist in scl meta package creation (4.76 KB, patch)
2014-02-18 20:47 UTC, Toshio Ernie Kuratomi
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1151400 None None None Never

Internal Links: 1151400

Description Toshio Ernie Kuratomi 2014-02-18 20:45:12 UTC
Description of problem:

The FHS says that /opt is a read-only, sharable hierarchy.  That means that state files (which are written during program execution) and config files (which may differ between two different systems) need to be installed somewhere other than /opt.

The FHS lists /var/opt and /etc/opt as the locations for those types of files.  We're supposed to use a vendor directory under those locations just like we do in /opt.

I've been working on an implementation of this here http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-scl-utils/  I'll attach some patches from that. 

Version-Release number of selected component (if applicable):
scl-utils-20140127-1.fc20.3.x86_64

Comment 1 Toshio Ernie Kuratomi 2014-02-18 20:46:55 UTC
Created attachment 864791 [details]
Changes to the rpm macros that define the filesystem paths for confdirs and statedirs

Comment 2 Toshio Ernie Kuratomi 2014-02-18 20:47:55 UTC
Created attachment 864792 [details]
Changes to the rpm macros that assist in scl meta package creation

Comment 3 Bohuslav "Slavek" Kabrda 2014-03-13 12:16:13 UTC
Why exactly is the collection sysconfdir defined as "%{_root_sysconfdir}/opt/%{scl_vendor}/scls/%{scl}/"? It seems to me that the "/scls/" part is sort of redundant. IMO we should keep this consistent with /opt by mimicking it - e.g. we should have "%{_root_sysconfdir}/opt/%{scl_vendor}/%{scl}/".

Comment 4 Toshio Ernie Kuratomi 2014-03-13 16:20:40 UTC
"/scls/" is in /opt as well.

I've debated whether it's redundant or not.  On the one hand, the vendor directories can contain more than scls.  So you could end up mixing scls with other software and data from vendors.  This would be a bit confusing.

On the other hand, if we're namespacing all of the scl names then it would be less likely that directories could clash.

If we're not namespacing the scl names, the likelihood of a clash would be much higher.

Comment 5 Bohuslav "Slavek" Kabrda 2014-03-14 08:15:40 UTC
(In reply to Toshio Ernie Kuratomi from comment #4)
> "/scls/" is in /opt as well.

Ah, I must've missed that. If "/scls/" is in /opt, than it of course also makes sense in /etc.

> I've debated whether it's redundant or not.  On the one hand, the vendor
> directories can contain more than scls.  So you could end up mixing scls
> with other software and data from vendors.  This would be a bit confusing.
> 
> On the other hand, if we're namespacing all of the scl names then it would
> be less likely that directories could clash.
> 
> If we're not namespacing the scl names, the likelihood of a clash would be
> much higher.

Although I don't like adding one more directory to the already-long-enough paths, I see your point.

Comment 6 Jan Zeleny 2014-04-08 11:56:44 UTC
Upstream ticket:
https://fedorahosted.org/SoftwareCollections/ticket/17

Comment 7 Jan Zeleny 2014-07-18 15:22:12 UTC
So I can finally move to this initiative. I have reviewed your patch proposals and they mostly look sane.

What puzzles me is the "/scls/" part of paths. While I understand the rationale, I don't agree with it. I mean do we realistically expect, even for the long term future, that there will be another content in there directories?

Comment 8 Toshio Kuratomi 2014-07-21 16:05:00 UTC
<nod>  To answer the second part of that first:  I do think that we're going to have more content in those directories.  Especially with the Fedora.next initiatives.  We're entering a period of experimentation and change for Fedora.  Using /opt/$vendor for things that don't fit in the normal FHS hierarchy are more likely in this time than any other.

However, as noted in Comment:4, if each SCL is inside a subdirectory that's named after a properly namespaced package name then we probably won't have to deal with filesystem conflicts between directories (because we've already had to ensure that package names are unique.)  So then it's only a question of mixing different categories of packages rather than having to deal with two packages wanting to use the same filename.

In general, I think having a small bit of hierarchy to make the separation will be better for sysadmins poking around in this directory structure.  Especially as it's entirely possible that not everything in here will be delivered via rpms.  So /opt/fedora/scls /opt/fedora/conda /opt/fedora/wheels and what have you will make it clearer for the sysadmin what they're looking at.  However, the hope would be that even if we plop all of these into the /opt/fedora/ directory we wouldn't have a file conflicts problem, we'd only have a problem for the sysadmin to be able to visually identify the directory they're looking for.

So all this to say -- I think it's better to use /scls/ in the path but I'm willing to compromise on it.

Comment 9 Jan Zeleny 2014-08-01 14:23:59 UTC
Thanks for the comment. I will trust your expertise on this and include the /scls/ in the paths. As I said, I was just unsure if we realistically expect any other content than SCLs and the answer seems to be positive so I have no problem with that part any more.

Comment 10 Fedora Update System 2014-11-14 09:50:25 UTC
scl-utils-20140815-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/scl-utils-20140815-2.fc20

Comment 11 Fedora Update System 2014-11-14 09:50:31 UTC
scl-utils-20140815-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/scl-utils-20140815-2.fc21

Comment 12 Fedora Update System 2014-11-15 09:10:40 UTC
Package scl-utils-20140815-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-20140815-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15095/scl-utils-20140815-2.fc21
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2014-12-12 11:24:34 UTC
scl-utils-20140815-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/scl-utils-20140815-3.fc20

Comment 14 Fedora Update System 2014-12-12 11:24:42 UTC
scl-utils-20140815-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/scl-utils-20140815-3.fc21

Comment 15 Fedora Update System 2015-01-03 19:09:02 UTC
scl-utils-20140815-4.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2015-01-03 19:10:59 UTC
scl-utils-20140815-4.fc20 has been pushed to the Fedora 20 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.