Subject: Re: [linux-audio-dev] ardour Q
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Jul 20 2001 - 07:12:33 EEST
><tongue-in-cheek response>
>Please, would people stop building libraries or binaries from source on
>a package-based system? It causes so many problems. If you are
>building a tool from source and it needs library X, I energetically
>encourage you to take the fifteen minutes to make RPMs of both the
>library and the tool. This will ensure several things:
>
> 1. That you really have all of the prerequisites for the library and
>that anyone else who uses this package (maybe you on a different
>computer) also has all of the prereqs. RPM does a fairly good ldd-style
>analysis of packaged binaries, and uses this information to generate
>dependencies.
The problem is that RPM cannot ensure that you have the prerequisites.
How can it do that when the "features" declared by every package I
have ever seen do not include actual "features" at all, but just 1 or
2 names of things that don't identify a version, bugfixes or anything
else. The fact that you might have foobar-3.4.5-1 installed doesn't
tell me enough unless foobar-3.4.5-1 uniquely identifies a feature set
that my application requires. Sometimes it does, sometimes it doesn't.
Because of the excessive sensitivity of C++ code to the build
environment (partly through much greater use of structures, inlining,
etc.), even if the version ID does uniquely identify a feature set of
a shared library, I can't be sure that the version you have installed
will actually work correctly.
There's other ways you can get bitten. Here's a classic case I ran
into early on when working on Quasimodo. The libtool RPM didn't
include a binary version of libltdl.so (the RPM pakcager had decided
that the RPM was "architecture independent", and thus shouldn't
include a binary library). So, an RPM that needed libltdl.so would
look for the relevant version of libltdl in the RPM database, find it,
and apparently install OK. Likewise, a naive or busy user who thinks
they are installing libltdl.so may conclude that they have done so.
However, when they try to compile an application that actually looks
for libltdl.so during the ./configure process, they discover that they
really don't have what they need. They then complain to *me* that "I
installed libtool", and I have to patiently explain that the package
they installed was built incorrectly. Guess who they want to believe,
me or RH? OK, so this particular problem gets fixed, but ...
This problem has been repeated over and over with the -devel versions
of packages, and it even comes up in poorly written configure scripts
and macros that test for some "global flag" that should mean "we
have/don't have feature X", rather than testing for feature X
itself. I myself was criticized for this problem in early Quasimodo
configure scripts.
./configure is an orthogonal approach to the problem of pre-requisite
testing, and its vastly more flexible than any of the package systems,
partly because its so, uh, configurable, and mostly because it tests
for what really matters: compile and run-time *details*. however,
configure doesn't have any way of helping you out if a test fails. all
it can say is "i tried this test, and it failed; you need to get your
system into shape". the user then turns around and says "how?" (see
the ardour-dev mailing list, almost every day ... :)
> 4. Building source and binary RPMs guarantees that you have a
>structured way to install, rebuild, and remove your software, with a
>well-designed system doing the bookkeeping for you.
The problem is that the bookkeeping is based only on what the .spec
file declares. Since this is never comparable to the kinds of tests
that ./configure performs, the bookkeeping is inadequate as a way to
test for compile or run-time prerequisites in all but the simplest of
cases. It works OK because most programs *are* the simplest of cases.
--p
This archive was generated by hypermail 2b28 : Fri Jul 20 2001 - 07:13:27 EEST