[Fedora-packaging] SCL discussion at yesterday's meeting, easy stuff

[Honza Horak]

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#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.

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