Re: Re: PROPOSAL: /opt/<provider>/<package>/]

On Friday 30 May 2003 04:05 am, Gerhard Muntingh wrote:
> On Thu, May 29, 2003 at 11:51:24AM -0600, Bart Whiteley wrote:
> > 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".
>
> Why not a configuration package?
>

Perhaps, but this doesn't change the argument 
in favor of /opt/<provider>/lib. 

> > 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 think logrotate should be patched to use /etc/opt/logrotate.d/ also
> if it exists.  And ofcourse the same for cron and init.
>

This is fine and well, but we have to solidify our internal
standards next week.  Any changes to cron, init, and logrotate
won't be available on a LSB platform for years. 


Maybe it would be helpful if someone would explain to me 
why /opt/<provider>/<package> is superior to 
/opt/<provider>/<what ever the provider feels is appropriate>. 

As long as things are under /opt/<provider>, namespace collisions
are avoided.  What more does /opt/<provider>/<package> buy?

-- 
Bart Whiteley <[email protected]>
Novell, Inc., the leading provider of information solutions
http://www.novell.com/