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

[Bart Whiteley]

Hello George, others. 

This is my first post, so bear with me.  I've been working with 
Doug Beattie on these issues.  I don't know how many of my 
thoughts he has forwarded along. 

I think this proposal is a step in the right direction.  I do, 
however, find it to be a bit too restrictive.  What if a company, 
such as IBM, had 10 or 20 "packages"?  What if there were 
base libraries, tools, or configuration data that were common 
to multiple "packages"?

I would prefer the standard to be flexible enough to allow
for the following:
/opt/<provider>/{lib, bin, include, ...}
Multiple "packages" could install binaries, libraries, etc. 
in to /opt/provider/bin or /opt/provider/lib.   These would
be libraries or tools that many "packages" might depend 
on.  In particular, this would be nice for SDKs, so that 
developers don't have to use multiple -I or -L flags to 
gcc, for instance. 

Also, I would prefer that configuration data be allowed to 
be in /etc/opt/<provider>/<something>, where <something>
does not necessarily correspond to a "package".  Similar 
arguments apply here.  Perhaps there are some configuration
files that are used by a lot of "packages".  

I don't think that this increased flexibility violates the spirit
of what the standard is trying to accomplish.  As long as files
are under {,/etc,/var}/opt/<provider>, namespace collisions
will be avoided (it then becomes the responsibility of the 
<provider> to avoid collisions under these directories between
their own packages, just as it is their responsibility to avoid 
collisions between init scripts named /etc/init.d/<provider>-*). 

As an example, I would prefer that a company could develop 
LSB compliant applications WRT the FHS by following
these simple guidelines:

- All static data be under /opt/<provider>
- All host-specific configuration data be under /etc/opt/<provider>
- All variable data be under /var/opt/<provider>
- Any file or directory that does not comply with one of the first three, 
  must be prefixed with "<provider>-" (and must have a very good 
  reason why it doesn't comply with one of the first three). 

This fourth rule covers init and cron scripts, as well as other 
things not currently covered in the specification (like 
/etc/logrotate.d/<provider>-*).

I look forward to hearing your thoughts on this matter. 

-- 
Bart Whiteley <bwhiteley at novell.com>
Novell, Inc., the leading provider of information solutions
http://www.novell.com/