Re: buildconf against installed APR

[Graham Leggett]

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

   In any case there are dozens of packages that use the same "kludge",
including gtk, glib, qt, and many others.

would tell you ;-).

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
rpmfind.net 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 et.al) 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.

Regards,
Graham
--

smime.p7s
Description: S/MIME Cryptographic Signature