This is mostly just me reporting things were decided and things that the FPC seems to have decided on so I'm going to go forward with the draft assuming that this is how things are going to be. I'll send out separate emails for the other things discussed so we can discuss them in isolation.
== Partial approval == FPC approved this portion of the draft: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approv...
minus the SCL Retirement section. The reason for not approving that section is that it's not finalized yet. That section will likely be voted on at next week's meeting so if you have comments on improving it, please let me know (IRC or an {{admon/question|| Comment}} in the draft will assure that I see your comment. This mailing list will let others participate in a discussion. I recommend doing both :-)
== Filesystem Location == A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
The location does need to include a vendor identifier. at the meeting we discussed /usr/scl/$vendor/$scl_name/ but if the vendor string made its way into the $scl_name I don't think people would object to /usr/scl/$scl_name (scl_name is like fdr-ruby1.9.3).
-Toshio
On Fri, Nov 01, 2013 at 12:28:28PM -0700, Toshio Kuratomi wrote:
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
From the peanut gallery over here, that seems sensible to me.
Toshio Kuratomi (a.badger@gmail.com) said:
== Filesystem Location == A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
The location does need to include a vendor identifier. at the meeting we discussed /usr/scl/$vendor/$scl_name/ but if the vendor string made its way into the $scl_name I don't think people would object to /usr/scl/$scl_name (scl_name is like fdr-ruby1.9.3).
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
Bill
On Fri, Nov 01, 2013 at 03:43:51PM -0400, Bill Nottingham wrote:
Toshio Kuratomi (a.badger@gmail.com) said:
== Filesystem Location == A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
[snip]
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
I suppose the counter example to the argument that because the directory is under /usr it is grafted onto the OS would be /usr/local. But I don't know that any of the FPC members were looking at it in this light.
-Toshio
On 11/01/2013 09:18 PM, Toshio Kuratomi wrote:
On Fri, Nov 01, 2013 at 03:43:51PM -0400, Bill Nottingham wrote:
Toshio Kuratomi (a.badger@gmail.com) said:
== Filesystem Location == A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
[snip]
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
I suppose the counter example to the argument that because the directory is under /usr it is grafted onto the OS would be /usr/local. But I don't know that any of the FPC members were looking at it in this light.
-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I thought in this discussion was already mentioned: distribution musn't touch anything in /usr/local.
We need the installation inside the /opt directory because some users are using it exactly as Bill mentioned.
Marcela
On Tue, Nov 5, 2013 at 6:29 AM, Marcela Mašláňová mmaslano@redhat.comwrote:
On 11/01/2013 09:18 PM, Toshio Kuratomi wrote:
On Fri, Nov 01, 2013 at 03:43:51PM -0400, Bill Nottingham wrote:
Toshio Kuratomi (a.badger@gmail.com) said:
== Filesystem Location == A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
[snip]
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
I suppose the counter example to the argument that because the
directory is under /usr it is grafted onto the OS would be /usr/local. But I don't know that any of the FPC members were looking at it in this light.
-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I thought in this discussion was already mentioned: distribution musn't
touch anything in /usr/local.
We need the installation inside the /opt directory because some users are using it exactly as Bill mentioned.
Isn't that exactly why we musn't touch anything inside /opt?
-J
Marcela
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Jon Ciesla wrote:
On Tue, Nov 5, 2013 at 6:29 AM, Marcela Mašláňová mmaslano@redhat.comwrote:
We need the installation inside the /opt directory because some users are using it exactly as Bill mentioned.
Isn't that exactly why we musn't touch anything inside /opt?
It seems reasonable to me that the Fedora project could be both an OS provider and an add-on provider. In its add-on provider role Fedora could register a provider name "fedora" with LANANA, and package SCLs for installation under /opt/fedora/<scl_name>. (I see that "rh", "rhat", "centos" and "suse" are already registered as provider names.)
Björn Persson
On 11/05/2013 05:30 AM, Björn Persson wrote:
Jon Ciesla wrote:
On Tue, Nov 5, 2013 at 6:29 AM, Marcela Mašláňová mmaslano@redhat.comwrote:
We need the installation inside the /opt directory because some users are using it exactly as Bill mentioned.
Isn't that exactly why we musn't touch anything inside /opt?
It seems reasonable to me that the Fedora project could be both an OS provider and an add-on provider. In its add-on provider role Fedora could register a provider name "fedora" with LANANA, and package SCLs for installation under /opt/fedora/<scl_name>. (I see that "rh", "rhat", "centos" and "suse" are already registered as provider names.)
"The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use."
That seems pretty clear that those are the only ones specifically reserved for the local system administrator.
"Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator."
Which implies the only requirement is that the SCL installer would have to ask before replacing a package (assuming /opt/<package>). The LANANA registration and subsequent package hierarchy would be simplest, safest, and most logical, imho.
On Thu, 7 Nov 2013, Joe Julian wrote:
Which implies the only requirement is that the SCL installer would have to ask before replacing a package (assuming /opt/<package>). The LANANA registration and subsequent package hierarchy would be simplest, safest, and most logical, imho.
The LSB folks at our weekly bug triage considered the bug filed by Matt Miller on the topic [1]. The FHS and LANANA space is mature without much activity, and so my comment 2 in that bug was designed to permit a 'fast-track' assignment of a /opt/fedora/ namespace, for use as the project sees fit
We need to do some infrastructure work with LANANA to communicate this well within the FHS documentation, but as Jeff's summary indicates, absent some major objection being surfaced, will, I think, be the way the LSB proceeds in its next update (usually done at six month intervals)
-- Russ herrold
On Thu, Nov 07, 2013 at 01:43:48PM -0500, R P Herrold wrote:
On Thu, 7 Nov 2013, Joe Julian wrote:
Which implies the only requirement is that the SCL installer would have to ask before replacing a package (assuming /opt/<package>). The LANANA registration and subsequent package hierarchy would be simplest, safest, and most logical, imho.
The LSB folks at our weekly bug triage considered the bug filed by Matt Miller on the topic [1]. The FHS and LANANA space is mature without much activity, and so my comment 2 in that bug was designed to permit a 'fast-track' assignment of a /opt/fedora/ namespace, for use as the project sees fit
We need to do some infrastructure work with LANANA to communicate this well within the FHS documentation, but as Jeff's summary indicates, absent some major objection being surfaced, will, I think, be the way the LSB proceeds in its next update (usually done at six month intervals)
-- Russ herrold
Thank Russ!
Reading the replies to the Linux Foundation bug report there's a few concerns that I think would help FPC members who are concerned by /opt:
* Preallocation of LANANA names sounds great! Thanks. * FPC members might still be concerned about clashes between software and registered LANANA names that weren't registered until recently such as Fedora when it gets pre-allocated. Thinking about it this weekend, I don't see much way around this except to actually update the FHS around /opt. Maybe something like the following changes:
A package to be installed in /opt must locate its static files in[...]the provider's LANANA registered name. +Distributions may utilize this structure to install software but must obey +the same rules as any other vendor.
[...]
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. [...] these reserved directories. + +The directories /opt/<provider> are reserved for vendors to install their +packages' files within. System administrators are cautioned that because +the list of LANANA provider names grows over time they should not make +arbitrary files and directories inside of /opt. Instead make local changes +in one of the /opt subdirectories listed above or in /srv.
[...]
-Distributions may install software in /opt, but must not modify or delete -software installed by the local system administrator without the assent of -the local system administrator.
+Vendors who install software in /opt must not modify or delete software +installed by the local system administrator without the assent of the local +system administrator. Since the /opt/<provider> hierarchies are reserved +for vendors, vendors are encouraged to limit their software installation to +the /opt/<provider> hierarchy belonging to them to avoid conflicts.
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACK...
* In the rationale section, I'm not sure I understand the purpose of: "Generally, all data required to support a package on a system must be present within /opt/<package>, including files intended to be copied into /etc/opt/<package> and /var/opt/<package> as well as reserved directories in /opt." My gut feeling is that the dual requirement is so that the sys admin can have a baseline to revert to or if they are using a network mount of the /opt hierarchy and want to bring up a new machine. With Fedora-provided rpms, the rpm should serve that same purpose so I think we can waive the requirement to have the files in /opt/<provider>... they can be present in only /etc/opt/<provider> and /var/opt/<provider>.
* In the FPC meeting we talked about whether /var/scls/<provider>/<scl>/log/<logfiles> or /var/log/scls/<provider>/<scl>/<logfiles> would be preferable and settled on the latter so that sysadmins could continue to find their logfiles under /var/log. Do you/the lsb have a feeling about that? My reading of usage of /opt is that the FHS would currently mandate /var/opt/<provider>/<scl>/log/<logfiles> -- not sure if this is something that could/should be changed. A rationale of why not to change it would be nice though.
limburgher, I know that you were at the last meeting and were championing the non-opt because of FHS/sysadmin overwriting concerns. Do you have anything to add to the above?
Thanks everyone, Toshio
On Mon, 11 Nov 2013, Toshio Kuratomi wrote:
Reading the replies to the Linux Foundation bug report there's a few concerns that I think would help FPC members who are concerned by /opt:
- Preallocation of LANANA names sounds great! Thanks.
* nod * The LSB / LANANA are 'follow along and document' in nature ** most ** of the time; exceptions exist, such as to initscript header expectations ... and expanding the expressiveness of those to help a given initscript solution -- BSD, Sys V, systemd, upstart -- is something that may need revisiting. Suggestions in the bug tracker and on the LSB mailing list welcome. Indeed, our process, call, and such are all open and meet mostly on a weekly cycle as noted in the point from my earlier email
- FPC members might still be concerned about clashes between
software and registered LANANA names that weren't registered until recently such as Fedora when it gets pre-allocated. Thinking about it this weekend, I don't see much way around this except to actually update the FHS around /opt. Maybe something like the following changes:
yes, but ... in theory a namespace collision might occur, but in practice, I think it is probably a remote possibility at best
A package to be installed in /opt must locate its static files in [...] the provider's LANANA registered name.
This focus on static libraries is a Fedora local decision, no? That it might properly be placed under a namespace in the control of the registrant as I see it -- something like: /opt/(project)/static/(hierarchy)
is something that the project might decide to do, as an example
How to properly go about USING such is manageable in the project's documentation, and adding healpers, either in managing the PATH (which SCL does as I read it), or via the FSF 'stow' package which may be worth a gander
- In the FPC meeting we talked about whether /var/scls/<provider>/<scl>/log/<logfiles> or /var/log/scls/<provider>/<scl>/<logfiles> would be preferable and settled on the latter so that sysadmins could continue to find their logfiles under /var/log. Do you/the lsb have a feeling about that?
it is not clear to me that matter down this far is in the scope of LSB / FHS mandate ... nothing of which I am aware in LSB/FHS publish mandates that a log has to housed in a file, for instance. Ditto using config _files_ -- pulling out of /etc/ or wherever is readily supplanted by, say, a LDAP query and a fallback default value
Once one is past /opt/<provider>/ the person owning that namespace ... owns it
My reading of usage of /opt is that the FHS would currently mandate /var/opt/<provider>/<scl>/log/<logfiles>
assuming for the sake of advancing the thread that /var/opt/ is under FHS specification, once we go below the 'well known' demarc of: /var/opt/<provider>/
specification of the package, the namespace is under the management of the project / package / provider
The LSB is mostly concerned with being able to expose to ISVs the presence of a defined enviroment stocked with behaviours when an LSB conformant environnment is asserted, and clearly communicating expected behaviours to providers. We provide many tools to test the same positive and negative expectations, which we call a 'certification' process
Distributions (projects) are mostly publishers of that functionality. They own stuff and control below the namespace demarcation point in the filesystem, and the LSB will not have in interest nor would it meddle below that point
If that was wiki markup for an LSB / FHS URI, please add it (or its final suggested text) and the target to which it applies to the bug noted above, or in a new bug as you see fit
Thank you
-- Russ herrold
On 11/05/2013 01:38 PM, Jon Ciesla wrote:
We need the installation inside the /opt directory because some users are using it exactly as Bill mentioned.Isn't that exactly why we musn't touch anything inside /opt?
-J
I guess FHS can be interprated differently according to comments I've heard until now. For example if you look on Wikipedia there are different description of content for /usr/local and /opt.
Marcela
On Tue, Nov 05, 2013 at 01:29:52PM +0100, Marcela Mašláňová wrote:
On 11/01/2013 09:18 PM, Toshio Kuratomi wrote:
On Fri, Nov 01, 2013 at 03:43:51PM -0400, Bill Nottingham wrote:
Toshio Kuratomi (a.badger@gmail.com) said:
== Filesystem Location == A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
[snip]
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
I suppose the counter example to the argument that because the directory is under /usr it is grafted onto the OS would be /usr/local. But I don't know that any of the FPC members were looking at it in this light.
-Toshio
I thought in this discussion was already mentioned: distribution musn't touch anything in /usr/local.
<nod> I think you're trying to speak to a different point than I am making. I'm not saying that we should touch anything under /usr/local. I'm saying that /usr/local is precedent for subdirectories of /usr/ that "live outside of the OS".
-Toshio
On Fri, Nov 01, 2013 at 03:43:51PM -0400, Bill Nottingham wrote:
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
That's interesting -- to me, this is exactly why the package name prefix makes sense and I see the filesystem location as less important.
Matthew Miller (mattdm@fedoraproject.org) said:
On Fri, Nov 01, 2013 at 03:43:51PM -0400, Bill Nottingham wrote:
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
That's interesting -- to me, this is exactly why the package name prefix makes sense and I see the filesystem location as less important.
While Fedora is not necessarily 'enterprise' in all its senses, I've seen many enterprises that take 'outside of the OS' to imply 'stored in different locations, on shared storage, on the network'. A location under /opt makes this simpler than a location that would live directly under /usr, and would match other third-party software possibly managed in that way.
Bill
On Fri, Nov 1, 2013 at 12:43 PM, Bill Nottingham notting@redhat.com wrote:
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
At last week's meeting some people were not on board with the idea that SCLs provided by Fedora in the mainstream Fedora Repositories are "outside the OS".
""" I still say "can't be in opt" but people seem to have decided that even though SCLs are part of Fedora, they aren't part of Fedora. I mean, I'm seeing the argument that even though we're shipping them, they aren't part of the OS. And I just don't understand that. """
@notting, are you able to explain this viewpoint any better? @tibbs -- I think you were the primary person asking for this question to be answered. Please feel free to correct me if I'm not getting the full gist of what you are concerned about.
-Toshio
Toshio Kuratomi (a.badger@gmail.com) said:
Ngggh. If the point is to have a stack that lives outside of the OS... then it should *live outside of the OS*, not be grafted into a subpoint of the OS. (IOW, I disagree.)
At last week's meeting some people were not on board with the idea that SCLs provided by Fedora in the mainstream Fedora Repositories are "outside the OS".
""" I still say "can't be in opt" but people seem to have decided that even though SCLs are part of Fedora, they aren't part of Fedora. I mean, I'm seeing the argument that even though we're shipping them, they aren't part of the OS. And I just don't understand that. """
@notting, are you able to explain this viewpoint any better?
Essentially, it's defining the borders of the OS differently. If you feel that the OS is 'all software shipped by Fedora in the everything repo', then you might feel that they shouldn't belong in /opt. I feel that the actual OS is smaller than "the total of everything that we ship", and so therefore /opt is a place to package other things that Fedora might produce.
If it makes it simpler to think of SCLs as additional 'products' that go on top of an OS, does that help? The way that F19/F20 is packaged now in a single repository may not reflect this, but I think the way that the three products are being discussed, with a separate 'environments and stacks' group, with a separate Fedora Commons group, etc. may make this clear.
Alternatively, if you look at enterprise releases + EPEL, I would say that you wouldn't consider EPEL 'part of the OS', and treating the same things in Fedora as part of the OS simply because they're part of the same repo isn't necessarily right.
Bill
On Tue, 2013-11-12 at 17:21 -0500, Bill Nottingham wrote:
Essentially, it's defining the borders of the OS differently.
I think everyone is aware that SCLs are "different", but it's not like we _have_ to throw away all the rules/expectations about everything.
If you feel that the OS is 'all software shipped by Fedora in the everything repo', then you might feel that they shouldn't belong in /opt. I feel that the actual OS is smaller than "the total of everything that we ship", and so therefore /opt is a place to package other things that Fedora might produce.
Your original remark was that "/opt is good because enterprises like to have different things be stored separately, and /opt is much easier to do this with than /usr/lib/scls" ... and I would 100% agree that if an enterprise produces an SCL for something, they might well want/require that to be stored differently and hence live in /opt. I could even accept that it's possible some (most maybe) will want that to be true for SCLs coming from software-collections.org and/or random other third parties.
But from Fedora itself?
If it makes it simpler to think of SCLs as additional 'products' that go on top of an OS, does that help? The way that F19/F20 is packaged now in a single repository may not reflect this, but I think the way that the three products are being discussed, with a separate 'environments and stacks' group, with a separate Fedora Commons group, etc. may make this clear.
Again, yes, SCLs will be different as an example "rubygem-rails" is compatible with the OS and changes as it does but say "scl-rails-4.0" has compatibility/upgrade/etc. guarantees that are separate from the OS and thus. you can install the same SCL on multiple versions of Fedora and get the same thing. That, to me, would be the main difference. But it's still from Fedora, and I'd still expect it to integrate into the OS to as high a standard as possible. Even if SCLs all came from a fedora-scls repo. (which I think would be a good idea), I'd still assume those things.
Alternatively, if you look at enterprise releases + EPEL, I would say that you wouldn't consider EPEL 'part of the OS', and treating the same things in Fedora as part of the OS simply because they're part of the same repo isn't necessarily right.
Depending on what you mean by "part of the OS' you'd get very different answers from me to that. Certainly my expectations for how well a package integrates into the OS would be very different between EPEL and a random third party repo.
And to agree again, while we've historically been handcuffed with the memories/problems of fedora-core and extras, I'd be very happy for Fedora to move away from it's single "fedora" repo. model ... but I'd want the differences between the repos. to be explicit and not deviate apart from that.
On Thu, Nov 14, 2013 at 12:10:44PM -0500, James Antill wrote:
Again, yes, SCLs will be different as an example "rubygem-rails" is compatible with the OS and changes as it does but say "scl-rails-4.0" has compatibility/upgrade/etc. guarantees that are separate from the OS and thus. you can install the same SCL on multiple versions of Fedora and get the same thing. That, to me, would be the main difference. But it's still from Fedora, and I'd still expect it to integrate into the OS to as high a standard as possible. Even if SCLs all came from a fedora-scls repo. (which I think would be a good idea), I'd still assume those things.
Yes, to all of this. :)
James Antill (james@fedoraproject.org) said:
If you feel that the OS is 'all software shipped by Fedora in the everything repo', then you might feel that they shouldn't belong in /opt. I feel that the actual OS is smaller than "the total of everything that we ship", and so therefore /opt is a place to package other things that Fedora might produce.
Your original remark was that "/opt is good because enterprises like to have different things be stored separately, and /opt is much easier to do this with than /usr/lib/scls" ... and I would 100% agree that if an enterprise produces an SCL for something, they might well want/require that to be stored differently and hence live in /opt. I could even accept that it's possible some (most maybe) will want that to be true for SCLs coming from software-collections.org and/or random other third parties.
But from Fedora itself?
Yes. Having SCLs in entirely different places merely depending on vendor seems inconsistent. And it's not as if "in /usr/scl" vs "in /opt" is a particularly useful 'higher level of integration' IMO.
Bill
On 11/01/2013 08:28 PM, Toshio Kuratomi wrote:
A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
I feel the need to add my POV about choosing /usr/scl for SCL prefix. FHS states: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." [1]
That seems to me like a no-go for having /usr/scl as a prefix for SCLs, because there surely are packages that need to write some files, probably not only databases. So I'd also vote for /opt since there are no such requirements.
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Honza
On Tue, Nov 05, 2013 at 04:34:47PM +0100, Honza Horak wrote:
On 11/01/2013 08:28 PM, Toshio Kuratomi wrote:
A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
I feel the need to add my POV about choosing /usr/scl for SCL prefix. FHS states: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." [1]
That seems to me like a no-go for having /usr/scl as a prefix for SCLs, because there surely are packages that need to write some files, probably not only databases. So I'd also vote for /opt since there are no such requirements.
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Although I favor /opt, this is not one of the reasons. Our interpretation of /opt is that we also cannot depend on it being read-write and host-specific. It looks like fhs developed /opt to be a vendor-friendly version of /usr. Therefore it is also read-only and shareable. The reasoning stems from FHS's decision to separate read-write and host-specific information from /opt:
""" Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information. """
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACK...
As stated in my Filesystem Location Part 2 email: https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717.htm...
"we also noted that no matter whether /usr or /opt was used, config files would still need to be placed somewhere under /etc and state files somewhere under /var."
-Toshio
On 11/05/2013 04:42 PM, Toshio Kuratomi wrote:
On Tue, Nov 05, 2013 at 04:34:47PM +0100, Honza Horak wrote:
On 11/01/2013 08:28 PM, Toshio Kuratomi wrote:
A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
I feel the need to add my POV about choosing /usr/scl for SCL prefix. FHS states: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." [1]
That seems to me like a no-go for having /usr/scl as a prefix for SCLs, because there surely are packages that need to write some files, probably not only databases. So I'd also vote for /opt since there are no such requirements.
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Although I favor /opt, this is not one of the reasons. Our interpretation of /opt is that we also cannot depend on it being read-write and host-specific. It looks like fhs developed /opt to be a vendor-friendly version of /usr.
In my understanding, this is exactly what you want (/opt/fedora or may-be /opt/scl/<more>)
Therefore it is also read-only and shareable. The reasoning stems from FHS's decision to separate read-write and host-specific information from /opt:
""" Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information. """
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACK...
As stated in my Filesystem Location Part 2 email: https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717.htm...
"we also noted that no matter whether /usr or /opt was used, config files would still need to be placed somewhere under /etc and state files somewhere under /var."
Correct - What is you problem with this?
Ralf
On Tue, Nov 05, 2013 at 05:34:19PM +0100, Ralf Corsepius wrote:
On 11/05/2013 04:42 PM, Toshio Kuratomi wrote:
On Tue, Nov 05, 2013 at 04:34:47PM +0100, Honza Horak wrote:
On 11/01/2013 08:28 PM, Toshio Kuratomi wrote:
A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
I feel the need to add my POV about choosing /usr/scl for SCL prefix. FHS states: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." [1]
That seems to me like a no-go for having /usr/scl as a prefix for SCLs, because there surely are packages that need to write some files, probably not only databases. So I'd also vote for /opt since there are no such requirements.
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Although I favor /opt, this is not one of the reasons. Our interpretation of /opt is that we also cannot depend on it being read-write and host-specific. It looks like fhs developed /opt to be a vendor-friendly version of /usr.
In my understanding, this is exactly what you want (/opt/fedora or may-be /opt/scl/<more>)
Yep, that was my argument for why /opt made sense.
Therefore it is also read-only and shareable. The reasoning stems from FHS's decision to separate read-write and host-specific information from /opt:
""" Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information. """
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACK...
As stated in my Filesystem Location Part 2 email: https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717.htm...
"we also noted that no matter whether /usr or /opt was used, config files would still need to be placed somewhere under /etc and state files somewhere under /var."
Correct - What is you problem with this?
No problem from me -- this is entirely sensible. I was pointing out to Honza Horak that /opt and /usr are similar in this regard and therefore either solution would need supplemental directory trees in /etc and /var to suit our needs.
-Toshio
On 11/05/2013 11:56 PM, Toshio Kuratomi wrote:
On Tue, Nov 05, 2013 at 05:34:19PM +0100, Ralf Corsepius wrote:
On 11/05/2013 04:42 PM, Toshio Kuratomi wrote:
On Tue, Nov 05, 2013 at 04:34:47PM +0100, Honza Horak wrote:
On 11/01/2013 08:28 PM, Toshio Kuratomi wrote:
A straw poll was taken about the filesystem location of SCLs. A few FPC members were willing to use /opt but others were heavily opposed to it. Everyone was okay with using /usr/scl (or the plural form /usr/scls). So I think that needs to become the scl root dir (is that the right term?) for Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well. I didn't bring this up at the meeting but one thing that influences me on this is that scls are inherently rpm managed and therefore mixing both our scls with third party scls does not seem like the same vendor-OS problem that /opt was designed to fix.
I feel the need to add my POV about choosing /usr/scl for SCL prefix. FHS states: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." [1]
That seems to me like a no-go for having /usr/scl as a prefix for SCLs, because there surely are packages that need to write some files, probably not only databases. So I'd also vote for /opt since there are no such requirements.
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Although I favor /opt, this is not one of the reasons. Our interpretation of /opt is that we also cannot depend on it being read-write and host-specific. It looks like fhs developed /opt to be a vendor-friendly version of /usr.
In my understanding, this is exactly what you want (/opt/fedora or may-be /opt/scl/<more>)
Yep, that was my argument for why /opt made sense.
Therefore it is also read-only and shareable. The reasoning stems from FHS's decision to separate read-write and host-specific information from /opt:
""" Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information. """
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACK...
As stated in my Filesystem Location Part 2 email: https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717.htm...
"we also noted that no matter whether /usr or /opt was used, config files would still need to be placed somewhere under /etc and state files somewhere under /var."
Correct - What is you problem with this?
No problem from me -- this is entirely sensible. I was pointing out to Honza Horak that /opt and /usr are similar in this regard and therefore either solution would need supplemental directory trees in /etc and /var to suit our needs.
That makes sense, I had to miss that point, thanks. Altough I'm still not persuaded /usr is somehow better than current /opt from technical perspective (keeping aside FHS POV for now) -- I don't remember any technical reason from couple of discussions here and there; the only problem with /opt is based on some uncertainty if /opt was designed for such purpose in FHS or not, right? If not, could someone sum up the main pros and cons of /opt (again, aside FHS perspective)?
My point is that since FHS has been labeled like obsolete not only once already, shouldn't we focus more on the technical details and if there are no differences, just prefer the current design for compatibility reasons?
Honza
On Thu, Nov 7, 2013 at 6:34 AM, Honza Horak hhorak@redhat.com wrote:
That makes sense, I had to miss that point, thanks. Altough I'm still not persuaded /usr is somehow better than current /opt from technical perspective (keeping aside FHS POV for now) -- I don't remember any technical reason from couple of discussions here and there; the only problem with /opt is based on some uncertainty if /opt was designed for such purpose in FHS or not, right? If not, could someone sum up the main pros and cons of /opt (again, aside FHS perspective)?
My point is that since FHS has been labeled like obsolete not only once already, shouldn't we focus more on the technical details and if there are no differences, just prefer the current design for compatibility reasons?
FHS is kinda a tangent but it's worth talking about: The FHS is not obsolete in the sense that when your car is obsolete you buy a new car and throw the old one out. It could use expansion and in one or two places a clarification but it still serves as a common understanding of what concerns affect the various major hierarchies of the filesystem and serves as a starting point for organizing the files to be placed on them. No one is going to throw out FHS and start over from scratch (if you want to do that, see gobo linux :-). However, there are two routes that can be taken:
1) Try to fit in with an existing FHS specified hierarchy. Ironically, that's what a proposal to put it in /opt is. /opt is designated by FHS as a place for vendors and local system admins to install code. If we want to install scls there we have to play by the expectations the FHS establishes for its use. Because multiple parties install code here, the FHS has to have rules about where code can be installed to avoid one set of software overwriting software installed by someone else.
Those of us who see /opt as an okay place to put (some of the files from) an scl think that we can specify a vendor directory and place them in there. Something like /opt/fdr/scls/scl-foo1.0/. However, others argue that we're late to the party. Since this is an area that the sysadmin is allowed to install into, the sysadmin may already have used the vendor string that we choose to install something else (that's why I use "fdr" instead of "fedora" in the above example... the chances of a collision with "fedora" seem even higher). We would then be overwriting their installed software which is not allowed.
2) Expand the system to include a new hierarchy for what we want to do. The advocates of using /usr/scls are essentially saying that the FHS doesn't provide a good place for scls to reside. We need to create a new hierarchy for them. That hierarchy/mountpoint happens to reside under /usr/.
-Toshio
On Thu, Nov 07, 2013 at 07:36:17AM -0800, Toshio Kuratomi wrote:
Those of us who see /opt as an okay place to put (some of the files from) an scl think that we can specify a vendor directory and place them in there. Something like /opt/fdr/scls/scl-foo1.0/. However, others argue that we're late to the party. Since this is an area that the sysadmin is allowed to install into, the sysadmin may already have used the vendor string that we choose to install something else (that's why I use "fdr" instead of "fedora" in the above example... the chances of a collision with "fedora" seem even higher). We would then be overwriting their installed software which is not allowed.
Looks like upstream FHS is committed to resolving this. See https://bugs.linuxfoundation.org/show_bug.cgi?id=1164. The upshot is that /opt/fedora will be explicitly reserved for our use. (This is not yet official but there does not seem to be any opposition.)
(Thanks Russ!)
Toshio Kuratomi wrote:
(that's why I use "fdr" instead of "fedora" in the above example... the chances of a collision with "fedora" seem even higher)
You think? It seems to me that "fdr" would be likely to collide with somebody's Frobnicated Doodad Remover or Fourier Data Recorder, or endless other possibilities.
Björn Persson
On Nov 7, 2013 9:35 AM, "Björn Persson" bjorn@xn--rombobjrn-67a.se wrote:
Toshio Kuratomi wrote:
(that's why I use "fdr" instead of "fedora" in the above example... the chances of a collision with "fedora" seem even higher)
You think? It seems to me that "fdr" would be likely to collide with somebody's Frobnicated Doodad Remover or Fourier Data Recorder, or endless other possibilities.
Franklin Delano Roosevelt :-)
So yeah, always the potential to conflict. I mentioned /opt/ fedoraproject.org/ somewhere sometime but, well, length.
-Toshio
On Tue, Nov 05, 2013 at 07:42:34AM -0800, Toshio Kuratomi wrote:
Although I favor /opt, this is not one of the reasons. Our interpretation of /opt is that we also cannot depend on it being read-write and host-specific. It looks like fhs developed /opt to be a vendor-friendly version of /usr. Therefore it is also read-only and shareable. The reasoning stems from FHS's decision to separate read-write and host-specific information from /opt:
Unfortunately, FHS is dead upstream. Linux Foundation made an attempt at resuscitation about two years ago, but that immediately stalled again.
I filed this https://bugs.linuxfoundation.org/show_bug.cgi?id=1164 after talking to Jeff Licquia at LinuxCon, but it hasn't gotten any response. If we feel that FHS continues to be important, maybe we need to get involved in that upstream.
On Tue, Nov 05, 2013 at 04:12:42PM -0500, Matthew Miller wrote:
Unfortunately, FHS is dead upstream. Linux Foundation made an attempt at resuscitation about two years ago, but that immediately stalled again.
I filed this https://bugs.linuxfoundation.org/show_bug.cgi?id=1164 after talking to Jeff Licquia at LinuxCon, but it hasn't gotten any response. If we feel that FHS continues to be important, maybe we need to get involved in that upstream.
<nod> -- Is there an FHS group to get involved with or does it need to be a reboot? Grab a few Debian, Ubuntu, Arch, gentoo, FSF, etc people to look at what shortcomings we find in the current FHS draft and work on having those addressed one at a time?
-Toshio
On Tue, 5 Nov 2013, Toshio Kuratomi wrote:
<nod> -- Is there an FHS group to get involved with
FHS is under LSB at LF -- meetings are weekly by dial in. Full details at, say: http://lists.linuxfoundation.org/pipermail/lsb-discuss/2013-September/007744...
which are the 'long form minutes' I post once a month, and which enumerate most of what one nedds to know to get started in participating
Real time minutes during the call are collaboratively produced in the 'obby'
IRC channels are on the Freenode network, in #lsb, and #lsb-meeting ... '-meeting' is used for bug triage
As I noted in the bug Matt cited, it was, sadly, filed in a tracker that I missed the filing on, due to travel
quick answer is that FHS would be easy to resurrect, but we have not seen much interest
-- Russ herrold
On Tue, 5 Nov 2013, Matthew Miller wrote:
I filed this https://bugs.linuxfoundation.org/show_bug.cgi?id=1164 after talking to Jeff Licquia at LinuxCon, but it hasn't gotten any response.
hmmm ... filed 2013-09-24
I do not recall seeing it in weekly bug triage, but I missed a couple when travelling
I have escalated it internally at the LSB
-- Russ herrold
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Björn Persson -
Honza Horak -
James Antill -
Joe Julian -
Jon Ciesla -
Marcela Mašláňová -
Matthew Miller -
R P Herrold -
Ralf Corsepius -
Toshio Kuratomi