Re: TODO

[Daniel Reed]

On 2004-11-14T14:56-0600, Bob Friesenhahn wrote:
) On Sun, 14 Nov 2004, Gary V. Vaughan wrote:
) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig
) You seem to be a victim of a package install where every package has
) used its own unique installation prefix.  It seems to me that most
) systems use just one or two installation prefixes.

[http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES]
        /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.

 ...

        The directories /opt/bin, /opt/doc, /opt/include, /opt/info,
        /opt/lib, and /opt/man are reserved for local system administrator
        use. Packages may provide "front-end" files intended to be placed in
        (by linking or copying) these reserved directories by the local
        system administrator, but must function normally in the absence of
        these reserved directories.

(It may be arguable that having to manually specify paths to find .pc files
to pkg-config is not functioning "normally"--at least not within the stated
goals of PKGConfig's developers--as Gary pointed out.)

 ...

        The use of /opt for add-on software is a well-established practice
        in the UNIX community. The System V Application Binary Interface
        [AT&T 1990], based on the System V Interface Definition (Third
        Edition), provides for an /opt structure very similar to the one
        defined here.

        The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a
        similar structure for /opt.

        Generally, all data required to support a package on a system must
        be present within /opt/<package>, including files intended to be
        copied into /etc/opt/<package> and /var/opt/<package> as well as
        reserved directories in /opt.



As opposed to:

[http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY]
        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]


The /usr/local hierarchy may be thought of as mimicking the /usr hierarchy
for packages that are installed outside of the local system's software
management infrastructure. (/usr/local is the default install prefix for the
autotools to gently enforce this.)

The /opt hierarchy, on the other hand, may be more widely used by
third-party software that does integrate with the local system's software
management infrastructure, but is not a part of the local system's core
installation.

The /opt hierarchy may also be used by operating system distributors who
*want* to isolate each package, and either manage a system-wide set of
$*PATH environment variables or manage symlinks from other well-known
locations (maybe as part of a simple form of software management).

There is no requirement that software installed into /opt make its presence
known (in well-known locations). Hence, to be reliable, PKGConfig would
either need to crawl /opt/*/lib/pkgconfig/ or demand that the installers
manually specify from which install prefix to pull information. Either way,
PKGConfig's reliable usefulness is reduced to being something like a means
of storing CFLAGS and CPPFLAGS preferences for specific instances of a
software package; it can not be relied upon in all cases as helping manage
systems with multiple versions of a package installed.

(That is, in a case where a .pc file might be installed in a well-known
location without the library and header files being installed in well-known
locations, an .la file could be similarly installed separately to provide
access to the same kind of information, just lacking the header file
component.)

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
There is a lot of food in a supermarket, too, but a supermarket isn't
the best place to hold a dinner party. -- Christopher Faylor