httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Pardon <l...@skopos.be>
Subject Re: buildconf against installed APR
Date Fri, 02 Dec 2005 09:30:08 GMT
> Both apr and httpd ship with generic spec files included. The apr spec 
> files are designed so that you can install apr-0.x and apr-1.x side by 
> side without conflicts,

   As far as the included apr spec files are concerned, this is simply
not true. 

   Last time I looked, the spec files for 0.9.7 and 1.2.2 use the same
package names, i.e. apr and apr-util. 

   True, there is a "%define aprver X" statement in the spec, and that
will cause the contents of the rpm to go in separate apr-X directories.

   But because of the name, rpm will consider apr-1.2.2 simply a later
version of apr-0.9.7, exactly as told. Therefore if you install 1.2.2 it
will obligingly _remove_  all the 0.9.7 stuff, including all the apr-0
dirs and their content. Bye-bye side-by-side.

   I am sure you are gonna tell me that, as a workaround, I can install
with "rpm --install" instead of the normal "rpm --upgrade" or "rpm
--freshen" but that is not standard, normally only used for kernel
installs, and dangerous in just about all other cases. 

   And there is no need for a workaround either. The apr is not the only
one that must be able to support multiple versions side-by-side.
Standard practice is to use different package names by including the
version number _in_ the package name (eg apr0 and apr1), as Oden
correctly did.


   As to the included httpd.spec, that is not "generic" either, if I may
say so. 

   As I pointed out a few weeks ago, it does not even build out of the
box on a clean machine. To reiterate: it mandates a separate,
pre-existing install of apr/apr-util or else it dies. The apr code is
right there in the httpd tarball but it has no purpose as you can't use
it, you have to go get apr rpm packages elsewhere. Either apr is bundled
or it is not bundled, one can't have it both ways.

   I know (or at least have the impression) that you feel strongly about
the spec files that you contributed, and I don't want to offend. But
there is definitely room for improvement, to say the least. A good spec
file - especially if it comes with the product - should build
everywhere, under any circumstances, not just on the author's machine
(and please don't take this as a personal attack, it is not meant as
one). 

   Best regards,

   Luc Pardon

Mime
View raw message