Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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

Perhaps two rpm specs, apr-util and apr-util-ssl to distinguish
the feature?

Bill

Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in

[Graham Leggett <mi...@sharp.fm>]

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

Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in

[Graham Leggett <mi...@sharp.fm>]

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

Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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.

Bill

Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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.

Bill

Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in

[Graham Leggett <mi...@sharp.fm>]

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

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

Regards,
Graham
--

Re: svn commit: r597923 - /apr/apr-util/trunk/build/rpm/apr-util.spec.in

[Graham Leggett <mi...@sharp.fm>]

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

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

Regards,
Graham
--