apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in
Date Mon, 26 Nov 2007 00:06:34 GMT
Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
>> -1; please revert.
>> all httpd and apr components build for ssl explicitly, on demand.
>> They don't automatically inflict crypto API's on the user.  See
>> archives esp httpd's for why this policy exists.
> The spec file is targeted at Redhat-like systems, and standard practice 
> on Redhat-like systems is to build against all the system libraries 
> typically available (but not necessarily installed on) Redhat-like systems.
> 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.

>> 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.

If we refactor to provide openssl support when libssl.so/libcrypto.so
when they are found is less harmful.  But in the meantime, as requested,
please revert.


View raw message