Status and outlook of LSB and FHS compliance of Fedora.

Gilles J. Seguin segg at infonet.ca
Sat Jun 5 12:31:02 UTC 2004


On Fri, 2004-06-04 at 17:22, Aaron Bennett wrote:
> David Kewley wrote:
> 
> >
> >>What about /opt?  From the FHS 2.3 document
> >>http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE14 , it's seems that
> >>all of Fedora's optional packages need to install into /opt/<packagename>.
> >
> >I don't read it this way.  The FHS 2.3 says, "/opt is reserved for the 
> >installation of add-on application software packages."  Nowhere does it say 
> >anything equivalent to, "add-on application software packages must be 
> >installed in /opt."  There's a big difference there, one that I'm willing to 
> >assume is intentional. :)
> >  
> Trust me here -- if I'm setting up a straw man, it's because it needs to 
> be burned...
> 
> How do you reconcile the thought that /opt an optional place to install 
> add-on software packages with what the FHS says about /usr/local?

> >       /usr/local : Local hierarchy
> >
> >
> >         Purpose
> >
> > The /usr/local hierarchy is for use by the system administrator when 
> > installing software locally. It needs to be safe from being 
> > overwritten when the system software is updated.

> > It may be used for programs and data that are shareable amongst
> > a group of hosts, but not found in /usr.
> >
> > Locally installed software must be placed within /usr/local rather 
> > than /usr unless it is being installed to replace or upgrade software 
> > in /usr. [27] <http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1450>
> >
> >  
> >
> I suppose that could best be read as "/usr/local" is machine specific, 
> while /opt is exportable and mountable.  At least that's how a Solaris 
> SysAdmin would probably take it.  But it's pretty wierd if that's the 
> case: it's ok to dump stuff into /usr/local/bin , but everything in /opt 
> needs to be in /opt/<packagename>/bin ?  Why? 
> 
> The best answer I can come up with is that the people at FHS didn't do 
> any better job of grappling with this then I am.  There are two issues:  
> what is an add-on, and where should it go?

/opt answer the problem of packages who are time limited and/or with
registration keys or both, for example.

Administrator can now replace faulty hard disk or reinstall the OS.
Requirements are there to allow this, that's it, that's all.
And is the historical reason as far that I know.
Searching LSB would give same reasons.

>   I suspect that in RHEL world 
> -- and you'd have to ask Red Hat RHEL product support for an answer -- 
> anything that is not distributed by Red Hat is an add-on.  Here in 
> Fedora world we have the Fedora Extras repository which is sanctioned by 
> Red Hat but not distributed or written by them.  It's more of a grey 
> area.  What about stuff from livna.org, that according to Red Hat 
> doesn't officially exist?  Is xmms-mp3 and 'add-on'?  Or a locally 
> installed software package?
> 
> Those are tough questions.
> 
> What I think happened with the FHS is it's trying to be all things to 
> all systems.  There are times when installing everything into /opt is a 
> good idea.  There are times when it's not.  There are times when 
> installing stuff into /svr is the right way to go... and times when it's 
> not.  I think that it's totally valid to have standard, canonical 
> locations for files.  I'm in favor of a Filesystem Hierarchy Standard.  
> Just not necessarily this one.  Whatever one we use, it has got to be 
> consistent.  We can't be moving stuff from /var/apache to /var/httpd to 
> /svr/httpd to /services/webserver to /services/something else every two 
> years.






More information about the fedora-devel-list mailing list