[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TODO
From: |
Daniel Reed |
Subject: |
Re: TODO |
Date: |
Sun, 14 Nov 2004 17:09:08 -0500 (EST) |
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
- Re: TODO, (continued)
- Re: TODO, Gary V. Vaughan, 2004/11/14
- Re: TODO, Bob Friesenhahn, 2004/11/14
- Re: TODO, Gary V. Vaughan, 2004/11/14
- Re: TODO, Patrick Welche, 2004/11/14
- Re: TODO, Bob Friesenhahn, 2004/11/14
- Re: TODO, Jacob Meuser, 2004/11/14
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO, Tor Lillqvist, 2004/11/15
- Re: TODO,
Daniel Reed <=
- Re: TODO, Jacob Meuser, 2004/11/14
- Re: TODO, Gary V. Vaughan, 2004/11/14
- Re: TODO, Ralf Wildenhues, 2004/11/15
- Re: TODO, Howard Chu, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO, Ralf Wildenhues, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO, Scott James Remnant, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15