2:28 p.m.
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_App...
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
2:39 p.m.
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.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:43 p.m.
Toshio Kuratomi (a.badger(a)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
3:18 p.m.
On Fri, Nov 01, 2013 at 03:43:51PM -0400, Bill Nottingham wrote:
Toshio Kuratomi (a.badger(a)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
6:29 a.m.
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(a)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(a)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
6:38 a.m.
On Tue, Nov 5, 2013 at 6:29 AM, Marcela Mašláňová <mmaslano(a)redhat.com>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(a)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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
7:30 a.m.
Jon Ciesla wrote:
On Tue, Nov 5, 2013 at 6:29 AM, Marcela Mašláňová
<mmaslano(a)redhat.com>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?
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
10:14 a.m.
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(a)redhat.com>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?
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.
12:43 p.m.
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
[1] https://bugs.linuxfoundation.org/show_bug.cgi?id=1164
8:39 p.m.
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
[1] https://bugs.linuxfoundation.org/show_bug.cgi?id=1164
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#OPTADDONAPPLICATIONSOFTWAREP...
* 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
12:01 p.m.
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
7:37 a.m.
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
8:55 a.m.
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(a)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
10:20 a.m.
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 ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:38 p.m.
Matthew Miller (mattdm(a)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
8:50 p.m.
On Fri, Nov 1, 2013 at 12:43 PM, Bill Nottingham <notting(a)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
4:21 p.m.
Toshio Kuratomi (a.badger(a)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
11:10 a.m.
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.
7:12 a.m.
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. :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:32 a.m.
James Antill (james(a)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
9:34 a.m.
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
9:42 a.m.
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#OPTADDONAPPLICATIONSOFTWAREP...
As stated in my Filesystem Location Part 2 email:
https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717....
"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
10:34 a.m.
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#OPTADDONAPPLICATIONSOFTWAREP...
As stated in my Filesystem Location Part 2 email:
https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717....
"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
4:56 p.m.
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#OPTADDONAPPLICATIONSOFTWAREPACKAGES
>
>As stated in my Filesystem Location Part 2 email:
>https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717.html
>
>"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
8:34 a.m.
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#OPTADDONAPPLICATIONSOFTWAREP...
>>
>> As stated in my Filesystem Location Part 2 email:
>> https://lists.fedoraproject.org/pipermail/packaging/2013-November/009717....
>>
>> "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
9:36 a.m.
On Thu, Nov 7, 2013 at 6:34 AM, Honza Horak <hhorak(a)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
10:08 a.m.
New subject: update on FHS position on opt
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!)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:34 a.m.
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
12:04 p.m.
On Nov 7, 2013 9:35 AM, "Björn Persson" <bjorn(a)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
3:12 p.m.
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.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4:28 p.m.
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
5:02 p.m.
New subject: (from: Fedora Packaging ML) SCL discussion at yesterday's meeting, easy stuff
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/007...
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
4:48 p.m.
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
3805
days inactive
3823
days old
packaging@lists.fedoraproject.org
32 comments
11 participants
participants (11)
-
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