Status and outlook of LSB and FHS compliance of Fedora.

Luciano Miguel Ferreira Rocha strange at nsk.no-ip.org
Fri Jun 4 18:26:06 UTC 2004


On Fri, Jun 04, 2004 at 09:40:10AM -0400, Aaron Bennett wrote:
> Phil Knirsch wrote:
> >Hi folks.
> >
> >I've been looking at how well Fedora is compliant with the latest LSB 
> >and FHS specifications lately.
> >
> 
> 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>.

The document says:
   /opt  is  reserved for the installation of add-on application software
   packages.

I don't think any Fedora package is an add-on to the system. And some
being optional, everything under /usr is. :)

> That's actually the Solaris way as well as, according to the "Rationale" 
>  part of this section, "a well establish practice in the UNIX community."

But in those days you couldn't do a rpm -e package (or the same for
debian/gentoo/etc.). The rationale was lost a few years ago.

Still, I like and use /opt and ~/opt for packages I compile. And I've
switched from ~/opt/{bin,share,...} to ~/opt/package/... (or am in the
process of). Less pain when I want to remove or upgrade a package.

> I used to make a living packaging things for Solaris, and Sun's 
> packaging standard clearly states that all add-on software goes to /opt.

Sun's java rpm doesn't in my linux system.

> I've always hated it.  Largely because have /opt/gnome/ , /opt/apache , 
> /opt/kde , etc starts to generate PATH variables that are horrible. 

But not difficult to manage. It can be computed at run-time.

> However, the nice thing about that is it avoids this sort of thing:
> 
> [abennett at burton abennett]$ cd /usr/bin
> [abennett at burton bin]$ ls | wc -l
> 2404
> 
> 2,404 files are in /usr/bin on my FC2 system!
> 
> Anyhow, if we are all taking about /svr, we should be talking about /opt 
> and the rest of the FHS.  I've never seen any RedHat product pay 
> attention to /opt.  Let's decide about both things -- there's little 
> point in disrupting 90% of our users to achieve 50% FHS compliance.

Why should any package from any vendor for any system that allows seamless
installation, removal, listing and verification have to go to /opt?

Now, most packages should be relocatable, but that's a different story.

Regards,
Luciano Rocha





More information about the devel mailing list