[lsb-discuss] SCL discussion at yesterday's meeting, easy stuff

[R P Herrold]

On Mon, 11 Nov 2013, Toshio Kuratomi wrote:

> > [1] https://bugs.linuxfoundation.org/show_bug.cgi?id=1164

> 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