On Thu, 2004-02-05 at 20:42, Robin Laing wrote: > [quote] > /usr/lib : Libraries for programming and packages > Purpose > > /usr/lib includes object files, libraries, and internal binaries that > are not intended to be executed directly by users or shell scripts. > Applications may use a single subdirectory under /usr/lib. If an > application uses a subdirectory, all architecture-dependent data > exclusively used by the application must be placed within that > subdirectory. > [/quote] Which is exactly what Fedora Core does. Executable files meant for the internal use of a package are placed in /usr/lib or /usr/lib(qual) often using the package name. For example, I have various things in /usr/lib/(package) for a package I maintain. There are libraries, perl modules, and such in there. All are executable code and only for use by one of various front-ends to the package. They generate MB or even GB of data that only the front-end program understands. Similarly, the /usr/bin/mozilla script executes the binary /usr/lib/mozilla-(version)/mozilla-bin. The use of mozilla-bin is so incomprehensible as to be useless to most humans. Thus there's a friendly script called /usr/bin/mozilla to make it apparently trivial to run Mozilla. > [quote] > /opt : Add-on application software packages > Purpose > > /opt is reserved for the installation of add-on application software > packages. > > A package to be installed in /opt must locate its static files in a > separate /opt/<package> or /opt/<provider> directory tree, where > <package> is a name that describes the software package and <provider> > is the provider's LANANA registered name. > [/quote] But you omit the most important quote of all, "Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator." OK, FHS says distributions _may_ install software to /opt. (May seems to imply they don't have to. For example, Debian doesn't and many hail it as the holy grail of perfection.) And _must not_ modify files maintained outside of an automated package management system. Fedora's RPM (and Debian) prefers to install software to /usr (which RPM explicitly supports sharing via network per FHS) but can install packages to /opt without destroying existing files (suffixes .rpmnew to conflicting files). In fact, you may note that you can ask RPM to install any package anywhere you choose including to /opt/packagename (if the package doesn't have paths hard-coded but most do). BTW, you're quoting from FHS 2.3 which was released last week. With regard to /opt FHS 2.3 is notably different from the FHS 2.2 spec which Fedora Core currently follows. > What about shared directories and links between different versions of > Linux. This could be an issue if different distros put configuration > files in different directories. An example here is Open Office again. > In the users directory is .openoffice that has a link to > /usr/lib/openoffice/program/soffice Seems like OpenOffice is broken to me. Let's say I want to install OpenOffice to /opt. I go to their website and download the installer. I run the installer on all my systems. Hey, I can install to /opt/openoffice. How convenient. Now my /home shared between 60 competing distros works right. Yay. > Now if I want to share this /home partition between different distro's > of Linux, the link could point to a non-existent file as OpenOffice > will be installed in /opt/openoffice or /usr/local. Now how do I fix > this problem easily? OpenOffice arguably doesn't belong in /usr/local (unless maybe you built it from source). > I do admit that Fedora is following the standard that states an > application can be fully put in a subdirectory of /usr/lib but as I > said earlier, if you download the binary from Mozilla and install it, > then it will install in the /usr/local/mozilla directory. Same with > OpenOffice or most other applications that I have installed without > using RPM's. Mozilla doesn't belong in /usr/local/mozilla at all (unless maybe you built it from source). Who's violating FHS here? The key there is this, "...applications that I have installed without using RPM's." If the app installs itself then it belongs in /opt/(something) but if you manually install it (e.g. from source or "cp myprog /usr/local/bin") then it belongs in /usr/local. If the system (i.e. RPM) installs the package then it belongs in /usr, it must not be installed under /usr/local, and may be installed to /opt/(something) under the proper circumstances. The problem, IMHO, is that many software developers, who don't produce entire operating systems, greatly underestimate the impact of slap-dash installation methods and ill-conceived file locations. Its not really so much that Fedora, Debian or whatever isn't following FHS but instead its that many high-profile software developers are not following anything remotely like FHS. When Fedora (or Debian) provides a FHS-compliant version of some package which conflicts with the original author's package then Fedora gets the blame. -- David Norris http://www.webaugur.com/dave/ ICQ - 412039
Attachment:
signature.asc
Description: This is a digitally signed message part
