Hello Graham,
It seems we'll have to agree to disagree as we obviously differ on
fundamental interpretation. It's hardly a matter of much concern anyway,
as most packagers will have their own spec file by now.
Before withdrawing from this discussion I'd like to add some comments,
if only for the benefit (?) of whoever else is reading this thread (if
anybody).
Graham Leggett wrote:
>
> 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
> install:
>
> 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.
>
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.
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.
> > 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")
Which - to me - means that it will happen all the time. To you, it
seems to mean that it will happen only in exceptional cases. Again, no
common ground on an essential issue.
> instead of rpm -i (meaning "install").
If you mean to say that they are opposed, I have to disagree, but
here at least I can provide (some form of) proof. From man 8 rpm:
[rpm -U ] is the same as install, except all other version(s) of
the package are removed after the new package is installed.
Note that is says "the same as". In fact, rpm -U is the same as -i if
no previous version is present, and the same as rpm -F (--freshen)
otherwise.
Note also that it says "version(s)" (plural). If I read that
correctly, you're heading for trouble even if you don't fall into the -U
trap, more on that below.
>
> > 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.
When I said "not standard", I meant "not usual". If you mean by
"standard" that it is documented, I agree, it is. But so are the
--nodeps, --ignoreos etc switches that let you bypass or disable the
extra safety that rpm offers above a simple configure/make/make install
sequence. That does not make them safe, unless you know exactly what you
are doing. It's not because man 1 rm does not warn against rm -rf /* as
root that it is "not dangerous at all" <g>.
If you are lucky, rpm -i will fail when you have an older version of
the same package installed. This is because it won't overwrite files
that have the same name. You would then have to do rpm -F (freshen).
Most people won't bother and do -U right away and let rpm figure it out.
This is one of the reasons why I said -U is "standard" and -i is not.
Now, if the packager has changed his mind between releases and
installs the new stuff - for example - into /usr/local whereas it was in
/usr previously, you're out of luck: rpm -i will work and you'll end up
with two versions in different dirs. Most packages have no need to
install multiple versions and are not designed for side-by-side install.
So you have a 50% chance that the wrong one will be picked up when
compiling against it. Any developer knows what this means. This is why I
say it is dangerous. rpm -U will prevent that from happening, and this
is also the second reason why I said that -U is "standard".
I say it is dangerous, you say it is not. Again, opinion, no common
ground, no proof possible.
Above I pointed out that the man page says that rpm -U will remove
"other version(s)" (plural). I have never tried it, but it makes sense.
So, imagine you have installed both v0.9.7 and v1.2.2, with the same
package name and with rpm -i trick.
Now comes the day that you want to upgrade apr-1.2.2 to apr-1.2.3.
But how ?
* You can't use rpm -i, it will fail because the apr-1 dirs are
already there.
* You can't use rpm -U because it will wipe out BOTH 0.9.7 and 1.2.2
and hose up your box.
* You can't use rpm -F (--freshen) because that is the same as -U in
this case.
Your only option is to remove 1.2.2 first so you can install again
with -i. But no sir: rpm -e (--erase) will fail because of existing
dependencies (it will tell you that httpd and svn need apr).
So you would have to erase httpd (and svn and ...) first, next
install (rpm -i) apr and then re-install httpd and svn. Of course you
can always bypass the dependency check and remove by using "rpm -e
--nodeps apr", and then install again with -i "the kernel way".
Do you still call that "standard" ? To me it's more like bending over
backwards.
>
> > 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
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.
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.)
> 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.
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.
> packages, the kernel style install was chosen.
>
With the "rpm -U trap" waiting to happen, IMHOBNIY. (IMHO But Not In
Yours ;-).
> > 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.
>
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).
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.)
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 ?
Your answer will be: "because I will have to undo it when APR gets
unbundled". 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.
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.
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.
> 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.
Your spec file takes away that convenience by ignoring the apr
sources that are present. So it defeats the purpose of bundling.
>
> > 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).
Yes, but they (RedHat et al) are ahead of the httpd developers in
that they (RedHat et.al) already unbundled apr in practice. 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.
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. You say that the package isn't arranged how I want it.
Given that we at least agree on the latter ;-) and given that I have
the liberty of using another spec file than the one from the tarball,
further argumentation seems fruitless. It is probably strolling off into
off-topic land anyway.
>
> Regards,
> Graham
> --
Kind regards,
Luc
