Re: Autoconf and apt

[Brian Dessent]

Ralf Wildenhues wrote:

> If the dependencies are already listed in apt's database, then 'apt-get
> build-dep libfoo' should be all you ever need.  If not, then I don't see
> how Autoconf can behave better than it does now: the mapping of software
> given as source to packaging names is still quite distribution-dependent.

Another issue is that sometimes you specifically *don't* want optional
functionality enabled, and you *do* want those library tests to fail.

Say I'm running a standard home workstation with no LDAP server to be
found and I'm building a package that has optional LDAP support.  I'd be
very annoyed if this configure script automatically installed openldap
headers and libraries in order to enable functionality that I have
specifically decided that I don't want or need.

And this gets even worse when packages have optional language bindings. 
Suppose I have no personal interest in or need for python but I'm
building a package with optional python module bindings.  I'd be quite
annoyed if this supposedly helpful feature decided that I now need all
of python installed just so it can enable an optional binding that I'll
never use.

The quintessential example of this kind of insanity would be php, which
has about three dozen various optional library bindings.  If the
configure script tried to helpfully auto-install all that cruft I think
it would be met with a swift control-C followed by nasty words from the
user.  My observation is that people that are building from source do so
because they want to have some measure of extra control that the binary
packages don't afford them, and this runs contrary to that notion.  If
the kitchen sink build was the actual desired behavior it can be had
with "apt-get build-dep php5" anyway, as Ralf said.

Brian