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 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
