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