[lsb-discuss] Re: PROPOSAL: /opt/<provider>/<package>/]

Thomas Sippel - Dau t.sippel-dau at imperial.ac.uk
Tue Jun 3 13:22:28 PDT 2003


Bart Whiteley wrote:
> 
> Are you saying that you are opposed to allowing /opt/<provider>/bin
> and /opt/<provider>/lib?  Your PATH of "/opt/*/bin:/opt/*/*/bin" would
> still work in this case.

... and many more contributions.

I think we should pin down how users should be expected to use it,
rather than prescribe the minutiae of what is under /opt. Thus,
instead of /opt/<package> I would prefer:

... 3.13.2

/opt/<namespace>

   A directory that provides a namespace under the management of a third
   party. A package to be installed in /opt must locate its static files in a
   separate /opt/<namespace> directory tree, where <namespace> is a name that
   describes the namespace coordinator.

   The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib,
   and /opt/man are reserved for local system administrator use.  Packages
   may provide "front-end" files intended to be placed in (by linking or
   copying) these reserved directories by the local system administrator,
   but must function normally in the absence of these reserved directories.

   Programs to be invoked by users must be located in the directory
   /opt/<namespace>/bin. If UNIX manual pages are included, then a set of
   generic man pages should be located in /opt/<namespace>/man and it should 
   use the same substructure as /usr/share/man.

   /opt/namespace may be subdivided further, with constructs such as
   /opt/namespace/package/version, in which case the user callables
   in /opt/namespace/bin should select a default or specific package 
   or version, by links or otherwise, as defined by the namespace coordinator.

   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.

...

In other words, the management of the namespace is entirely handed over
to the namespace coordinator, subject to the "sanity check" that they 
should put their user callable commands into /opt/namespace/bin.

The "namespace coordinator" can be the sysadmin on behalf of those who
do not coordinate themselves, a vendor, a division of a vendor or a 
group of vendors. Maybe we should demand a 00info file in /opt/namesapce
detailing the website or email address of the namespace coordinator, but
that is about it. Thus things installing into /opt/<namespace> can be 
installed without checking, and the coordinator flamed if they make a mess
of it.

N.B. a "PATH" of /opt/*/bin will not generally work, as there is no 
coordination across namespaces, so /opt/fred/bin/date may do something
different to /opt/bill/bin/date, and the system behaviour depends on 
the order.

Any scheme that is more prescriptive will fail in the end, as packages
get bought up (/opt/software-associates anyone ?), providers merge or
subdivide, or feel their packages should not be too closely associated
with each other. Even the morass that is /opt/SUNW* (on Solaris) is not 
really avoidable.

Maybe lanana can actually provide for assigning these namespaces to whoever
wants to coordinate them, but I think an informal mechanism works just as 
well.

                                Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk
*   voice: +4420-7594-6912 (day)
*   fax:   +4420-7594-6958
*   snail: Thomas Sippel - Dau
*          Linux Services Manager
*          Unix Support Group
*          Information and Communication Technologies
*          Imperial College of Science, Technology and Medicine
*          Exhibition Road
*          London SW7 2BX
*          Great Britain




More information about the lsb-discuss mailing list