httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: buildconf against installed APR
Date Sat, 03 Dec 2005 08:54:01 GMT
Luc Pardon wrote:

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

To install two major versions of the same package, use the following to 

rpm -i packagename.rpm

Packages in the v0.x branch and the v1.x branches are designed not to 
conflict with each other.

For examples of another RPM package that is installed by default in this 
way, see the kernel RPMs.

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

This will only happen if you use the rpm -U (meaning "upgrade") instead 
of rpm -i (meaning "install").

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

It's not dangerous at all, and quite standard. See the RPM docs for details.

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

This is an ugly kludge. There are two techniques to handle this. One is 
the kernel way, the second is by publishing a "-compat" library for the 
old version. As "-compat" libraries typically don't have "-devel" 
packages, the kernel style install was chosen.

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

That is the intention.

The APR is a completely separate library, it has no business being 
binary packaged with httpd. If it is, how do you install a binary 
package of httpd+apr with a binary package of subversion+apr? You don't, 
as you get conflicts.

APR is packaged in the httpd tarball for historical and convenience 
reasons for people building from source.

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

You can.

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

If it doesn't build on your machine, I definitely want to hear about it, 
but so far it seems that it does build, the package just isn't arranged 
how you want it.

I can assure you that a lot of thought has gone into the APR and the 
Solaris packaging, for the purpose of launching APR as the standalone 
package that it should be. There is a lot of precedence for the current 
layout (the RPMs were originally Redhat RPMs, with the patches and a lot 
of the file moving removed).


View raw message