[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TODO
From: |
Jacob Meuser |
Subject: |
Re: TODO |
Date: |
Sun, 14 Nov 2004 17:02:33 -0800 |
User-agent: |
Mutt/1.4.2i |
On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote:
> 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.)
huh? so pkg-config is supposed to look in _every_ directory
to find .pc files?
besides the second part of what you quoted is what should have
happened on Gary's system, so instead of all the separate paths
under /opt, there would have simply been /opt/lib/pkgconfig.
> ...
>
> 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,
yes, because they "*want* to isolate each package", but the
administrator failed to "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)."
> 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.
_any_ tool that needs information that is hidden from it will of
course not be as functional as it could be.
> (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.)
what?
> --
> 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
--
<address@hidden>
- Re: TODO, (continued)
- Re: TODO, Scott James Remnant, 2004/11/15
- 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, 2004/11/14
- Re: TODO,
Jacob Meuser <=
- 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
- Re: TODO, Scott James Remnant, 2004/11/15