Re: TODO

[Jacob Meuser]

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>