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 Mon, 05 Dec 2005 21:08:52 GMT
Luc Pardon wrote:

>    Yes, that was precisely my point. I know of no other packages -
> except the kernel and (your version of) apr - that are installed by
> default in this way. For all other packages - to the best of my
> knowledge - rpm -U is the default way. It is not for naught that kernel
> upgrade how-to's warn explicitly to use -i and not -U.
>    Therefore, users of your packages will install with -U out of habit,
> wipe out the v0.x version and hose up their systems. It's not what I
> call the principle of least surprise.

Not true - if people have packages on their system that use apr v0.x, 
they will get a warning and rpm -U will fail.

>    But you say that -i is normal, I say -U is normal, so we have no
> common ground here and neither of us would be able to supply hard
> figures to convince the other.

You are missing the end goal of APR. APR v0.x will go away in time, and 
the plan is for this to happen sooner rather than later.

If you come to the ASF for packages, you're going to get what we 
consider to be our best packages, and that at the moment is APR v1.x. 
Distro maintainers are likely to take a far more conservative approach, 
and stick to httpd v2.0 (and thus APR v0.9). We hope to change that over 
time. We are not going to change that however by bending over backwards 
to binary package v0.9.x. We want people to upgrade to httpd v2.2 and 
apr v1.x, that is why they are packaged as they are.

>    If you consider that an ugly kludge, fine, that is your personal
> opinion. I don't believe it is documented as a kludge anywhere, so I
> consider it a matter of taste. Matters of taste are not to be the
> subject of discussion (as are colors and women, as any Ancient Roman
> would tell you ;-). 
>    In any case there are dozens of packages that use the same "kludge",
> including gtk, glib, qt, and many others.

These are few examples of libraries that build major version numbers 
into their names, the vast majority don't.

>    Besides, even if it is a kludge, it is only fitting, no <g>? (I mean
> the need to support two versions for a project as young as APR does not
> reflect positively on APR as a reuseable library.)

For historical reasons, httpd v2.0 depends on apr v0.9. To say that this 
doesn't reflect positively on APR is meaningless, as this is an external 
dependancy from just one project (subversion will build against either 
v0.9 or version 1.x).

>> the kernel way, the second is by publishing a "-compat" library for the
>> old version. As "-compat" libraries typically don't have "-devel"
>     I don't know what gave you that impression. A quick search on
> or the like on "*compat*devel" turns up plenty of
> counter-examples. This seems only logical: a library without header
> files (which is what typically goes into -devel) is of limited use in an
> open source world.

Ok, fair enough. But the purpose of the -compat library is to allow 
older packages that have not yet upgraded (eg httpd v2.0) to coexist 
beside the current preferred build (apr v1.x).

>    But I do happen to agree that "compat" is not the right way, if for
> different reasons. With aprX you could have apr2 alongside apr0 and
> apr1, if/when needed.

-compat is the way most distributions handle this issue when it arises.

>      I am not saying that your httpd.spec file should build a binary
> httpd rpm that _contains_ the apr binaries. I am happy with separate
> packages (assuming that httpd is dependent on any apr 1.x and not on
> 1.2.2 specifically).

httpd depends on a minimum level of APR like any binary RPM, it does not 
depend on a static snapshot of APR.

>      I am saying that the httpd.spec file should build _separate_ binary
> apr and apr-util packages _from_the_same_tarball_. (I believe that I
> posted that here already, after running into this issue and asking
> here.)

I disagree. The APR project should build and ship APR binaries as it 
sees fit. It stands alone from the httpd project, doing what you suggest 
is a step backwards.

>      As you know (but others may not) one spec file can build several
> packages from a single tarball. The RedHat package file that you (and I)
> used as a starting point does this already: it builds httpd,
> httpd-devel, httpd-manual and mod_ssl rpm's. So why not apr and apr-util
> as well ?

Because APR is a separate project that by design wants to be independant 
of httpd.

>     Your answer will be: "because I will have to undo it when APR gets
> unbundled".

APR has been unbundled a while ago. It exists in the httpd source tree 
for historical reasons. You'll notice Redhat and others don't build apr 
RPMs from httpd's SRPM, which is exactly the direction APR wants to take.

> And of course that is correct. And I also happen to agree
> that it should be unbundled sooner rather than later. But this has not
> happened, and it does not seem a priority for the developers either. 

It has quite a while ago - see the apr-devel archives for details.

>    But on the other hand it is not that much work that would have to be
> undone. It should as simple as a merge of the contents of the apr and
> httpd spec files. You could even add a "%define apr_bundled 1|0" to suit
> everybody.

And we would be back to a bundled httpd and apr, the step backwards I 
mentioned earlier.

>    In fact, after bringing this up a month or so ago, I started doing
> just that. Unfortunately, I failed, mainly because the httpd tarball
> throws all the apr header files into the same dir. As it turns out, it
> is impossible to tell from the file name whether a header file belongs
> to apr or apr-util (duh!), so you'd need exhaustive lists of the header
> files in the %file sections. Except for the maintenance issue that is
> easy enough (with rpm -ql on an existing package) but I had no more time
> and  - more importantly - I don't think it has any chance of being
> accepted anyway.

That would be because httpd, apr and apr-util are separate packages. 
Combining them, as you saw first hand, just isn't practical.

You will notice that httpd, apr and apr-util each have independant 
./configure scripts, and are built independantly of each other. There is 
a reason for this.

>> APR is packaged in the httpd tarball for historical and convenience
>> reasons for people building from source.
>     Yes, but these are the very same people that you are providing your
> spec file for, no ? Others would use pre-built binary rpm's.

No - they are provided for people who don't wish to run the conservative 
options provided by distro vendors, but who require the most recent 
release, while at the same time keeping the convenience of binary 
packaging systems like RPM.

>      Yes, but they (RedHat et al) are ahead of the httpd developers in
> that they (RedHat already unbundled apr in practice.

As do we.

> In fact, any
> packager has the right to package as he wants. But your spec file is
> shipping with the httpd project itself, therefore it should match the
> project's current state (i.e. bundled APR). As I said, I'm not opposed
> agains standalone packages for APR.

The packaging tracks best practice for the platform and the packaging 
system, and the goals moving forward for the httpd and apr projects. The 
packaging doesn't "have to" do anything that isn't aligned with its goals.

>    Anything that doesn't build out of the box on a clean machine is
> broken in my book. You say that is is working as designed. I say that
> this design may be valid one day, when apr gets unbundled, but that day
> has not come yet.

Then we must agree to disagree.


View raw message