Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 64.49.220.200 as permitted sender)
Message-ID: <45745.84.233.182.145.1196074240.squirrel@www.pier29.net>
In-Reply-To: <474A0E0A.4050706@rowe-clan.net>
References: <20071124220612.0F9731A9832@eris.apache.org>
    <4749D417.90603@rowe-clan.net> <474A0457.9090501@sharp.fm>
    <474A0E0A.4050706@rowe-clan.net>
Date: Mon, 26 Nov 2007 12:50:40 +0200 (SAST)
Subject: Re: svn commit: r597923 -
     /apr/apr-util/trunk/build/rpm/apr-util.spec.in
From: "Graham Leggett" <minfrin@sharp.fm>
To: dev@apr.apache.org
Cc: "Graham Leggett" <minfrin@sharp.fm>,
 dev@apr.apache.org,
 commits@apr.apache.org
User-Agent: SquirrelMail/1.4.8-4.0.1.el4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

On Mon, November 26, 2007 2:06 am, William A. Rowe, Jr. wrote:

>> It makes no sense to distribute a library that contains support for SSL,
>> and yet that support comes switched off as standard.
>>
>> The RPM spec file is not intended as a generic build spec that applies
>> for other systems, like Solaris, Windows or Netware (etc).
>
> It makes complete sense.  Most distros ship mod_ssl as a separate package
> from httpd, and for good reasons.  It makes it trivial to provide the
> crux of what httpd does, without ssl/tls cryptography.

This can only happen if the underlying library supports this, and in the
case of apr-util, it doesn't. Nor can we easily "fudge" support for this,
because apr-util is a single monolithic library.

If you look at the Redhat-provided spec file for httpd (or ours, which is
derived from Redhat's and simplified), you will see that it splits up the
httpd final install tree into separate packages for server, mod_ssl, docs,
etc. It can only do this because the httpd build itself splits the end
binaries up this way, using the standard "modules" mechanism to do so. It
is not up to RPM to try and "paper over" flaws in the build system.

RPM builds need to operate within the wider constraints imposed by the
autodetection features of autoconf/automake.

Right now, the spec file is still wrong, because the spec file doesn't
address the dependencies that apr has on sqlite and friends. When RPM
triggers a build, autoconf/automake are oblivious to RPM, and will happily
include SSL, sqlite, postgres, etc if the headers are correctly installed
on the builder's build machine.

If the spec file is silent about these autoconf autodetected dependencies,
the RPM based system will happily let you install the RPM without warning
you that those extra dependencies are also required. As soon as you try
and use the library for anything useful, it will suddenly fail with
linking errors, because ssl, sqlite and friends are missing, and the RPM
system had no idea these were required, and so didn't warn the user.

The RPM needs to either explicitly include these dependencies, or
explicitly exclude them.

If you want there to be RPM packages called apr-ldap, apr-ssl, or apr-db,
this can only be possible if the autoconf/automake build creates
apr-ldap.so, etc. RPM cannot be expected to magically fix flaws in the
underlying build.

The next question is whether these features should default to on, or
default to off.

APR is widely available, in various conservative versions, on most (if not
all) RPM systems. A consumer of our RPM is probably doing so because of a
need for a more bleeding edge version of APR than that available by
default on their system, and so it makes sense for the features to be
switched on. RPM handles this by refusing to continue if the required
dependencies are missing, and there are standard procedures to either
provide those dependencies, or exclude them, as the admin requires.

>>> Perhaps two rpm specs, apr-util and apr-util-ssl to distinguish
>>> the feature?
>>
>> This breaks the "principle of least astonishment" behaviour of RPM spec
>> files.
>
> Irrelevant.  Astonishment that another/a different package is required
> is far less risky than Astonishment that package dependencies have brought
> you software in violation of local law, or that you as a packager have
> broken export laws.

RPM explicitly tells you that it depends on openssl and will refuse to
proceed if openssl is missing. As a result, there is no way that a user
could "accidently" download and install openssl without explicit action by
that user, thus removing all opportunity for any potential astonishment.

That said, spec files do support conditional variables that can be used to
include or exclude behaviour as required, at the cost of added complexity
to the spec file.

Will this address your concerns?

Regards,
Graham
--