You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Temme <sa...@temme.net> on 2005/12/01 21:38:12 UTC
buildconf against installed APR
OK, I've been poking at the buildconf script a little bit. The
following patch:
Index: buildconf
===================================================================
--- buildconf (revision 351458)
+++ buildconf (working copy)
@@ -53,24 +53,32 @@
#
should_exit=0
-apr_found=0
-apu_found=0
+apr_found="no"
+apu_found="no"
for dir in $apr_src_dir
do
- if [ -d "${dir}" -a -f "${dir}/build/apr_common.m4" ]; then
- echo "found apr source: ${dir}"
- apr_src_dir=$dir
- apr_found=1
- break
+ if [ -d "${dir}" ]; then
+ if [ -f "${dir}/build/apr_common.m4" ]; then
+ echo "found APR source: ${dir}"
+ apr_src_dir=$dir
+ apr_found="source"
+ break
+ fi
+ if [ -f "${dir}/bin/apr-1-config" ]; then
+ echo "found installed APR in: ${dir}"
+ apr_src_dir=$dir
+ apr_found="binary"
+ break
+ fi
fi
done
-if [ $apr_found -lt 1 ]; then
+if [ x$apr_found = "xno" ]; then
echo ""
- echo "You don't have a copy of the apr source in srclib/apr. "
+ echo "You don't have a copy of the Apache Portable Runtime
version 1.x. "
echo "Please get the source using the following instructions,"
- echo "or specify the location of the source with "
+ echo "or specify the location of an installed copy with "
echo "--with-apr=[path to apr] :"
echo ""
echo " svn co http://svn.apache.org/repos/asf/apr/apr/trunk
srclib/apr"
@@ -80,19 +88,27 @@
for dir in $apu_src_dir
do
- if [ -d "${dir}" -a -f "${dir}/Makefile.in" ]; then
- echo "found apr-util source: ${dir}"
- apu_src_dir=$dir
- apu_found=1
- break
+ if [ -d "${dir}" ]; then
+ if [ -f "${dir}/Makefile.in" ]; then
+ echo "found APR-Util source: ${dir}"
+ apu_src_dir=$dir
+ apu_found="source"
+ break
+ fi
+ if [ -f "${dir}/bin/apu-1-config" ]; then
+ echo "found installed APR-Util in: ${dir}"
+ apu_src_dir=$dir
+ apu_found="binary"
+ break
+ fi
fi
done
-if [ $apu_found -lt 1 ]; then
+if [ x$apu_found = "xno" ]; then
echo ""
- echo "You don't have a copy of the apr-util source in srclib/apr-
util. "
+ echo "You don't have a copy of the APR Utility Library version
1.x. "
echo "Please get one the source using the following
instructions, "
- echo "or specify the location of the source with "
+ echo "or specify the location of installed copy with "
echo "--with-apr-util=[path to apr-util]:"
echo ""
echo " svn co http://svn.apache.org/repos/asf/apr/apr-util/
trunk srclib/apr-util"
@@ -128,22 +144,23 @@
cross_compile_warning="warning: AC_TRY_RUN called without default to
allow cross compiling"
-if [ -d srclib/apr ]; then
+if [ x$apr_found = "xsource" ]; then
echo rebuilding $apr_configure
- (cd srclib/apr && ./buildconf) || {
+ (cd ${apr_src_dir} && ./buildconf) || {
echo "./buildconf failed for apr"
exit 1
}
- rm -f srclib/apr/apr.spec
+ rm -f ${apr_src_dir}/apr.spec
fi
-if [ -d srclib/apr-util ]; then
+if [ x$apu_found = "xsource" ]; then
+ abs_apr_src_dir=$(cd "${apr_src_dir}" && pwd)
echo rebuilding $aprutil_configure
- (cd srclib/apr-util && ./buildconf) || {
+ (cd ${apu_src_dir} && ./buildconf --with-apr=${abs_apr_src_dir})
|| {
echo "./buildconf failed for apr-util"
exit 1
}
- rm -f srclib/apr-util/apr-util.spec
+ rm -f ${apu_src_dir}/apr-util.spec
fi
echo copying build files
(also attached) gets rid of all the hardcoded references to srclib/apr
{,-util}, recognizes an installed copy vs. a source tree and builds
configure only in the latter case. However, I keep running into
problems:
[sctemme@Graymalkin] trunk $ ./buildconf --with-apr=/Volumes/Files/
asf/apr-1.2.x --with-apr-util=/Volumes/Files/asf/apr-1.2.x
found installed APR in: /Volumes/Files/asf/apr-1.2.x
found installed APR-Util in: /Volumes/Files/asf/apr-1.2.x
copying build files
cp: /Volumes/Files/asf/apr-1.2.x/build/find_apu.m4: No such file or
directory
cp: /Volumes/Files/asf/apr-1.2.x/build/find_apr.m4: No such file or
directory
cp: /Volumes/Files/asf/apr-1.2.x/build/apr_common.m4: No such file or
directory
cp: /Volumes/Files/asf/apr-1.2.x/build/PrintPath: No such file or
directory
cp: /Volumes/Files/asf/apr-1.2.x/build/config.sub: No such file or
directory
cp: /Volumes/Files/asf/apr-1.2.x/build/config.guess: No such file or
directory
rebuilding srclib/pcre/configure
rebuilding include/ap_config_auto.h.in
rebuilding configure
rebuilding rpm spec file
fixing timestamps for mod_ssl sources
Note the cp turds: those files are not installed along with APR, so
buildconf cannot copy them over. How come I or no one else noticed
this ever? Probably because these files are not cleaned up by make
distclean and ignored by svn, so they stick around and are re-used.
To run into this, you need a clean svn checkout, or blow the build
directory away and svn up.
I guess this makes it pretty much impossible to build an svn checkout
against an installed APR:
[sctemme@Graymalkin] trunk $ ./configure
./configure: line 1502: syntax error near unexpected token `Apache,'
./configure: line 1502: `APR_ENABLE_LAYOUT(Apache, errordir iconsdir
htdocsdir cgidir)'
Foom. We're done. Unless we can make APR bring those files along for
us in the installation, we have no access to them.
Of course, all of the above are available in the release tarball,
since that has buildconf run on it before being rolled.
So, how can we make this useful? I guess we have to figure out why
one would want to run buildconf and I'm coming up with the following:
1) Bootstrap an svn checkout against an apr, apu checkout.
This is what we use it for.
2) Bootstrap an svn checkout against an installed APR. This
is currently broken as described above.
3) Reconfigure a release drop with autofoo from an installed
copy of APR if/when building against a newer/older install
4) Reconfigure a release drop to suck in autofoo from a
module dropped into the tree
5) ... (your use case here)
Thoughts? Ideas? I'd like to hammer out the above list before I do
more work on the patch.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: buildconf against installed APR
Posted by Oden Eriksson <oe...@mandriva.com>.
fredagen den 2 december 2005 15.31 skrev Joe Orton:
> [corrected dev list]
>
> On Fri, Dec 02, 2005 at 02:46:55PM +0100, Oden Eriksson wrote:
> > apr-0.9.3-deplibs.patch:
>
> Already upstream.
It applies cleanly to apr-1.2.2
[...]
> > apr-util-1.2.2-postgresql.diff:
>
> If you make the test conditional and re-submit it this looks like it is
> needed.
Like the attached one?
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
Re: buildconf against installed APR
Posted by Joe Orton <jo...@redhat.com>.
[corrected dev list]
On Fri, Dec 02, 2005 at 02:46:55PM +0100, Oden Eriksson wrote:
> apr-0.9.3-deplibs.patch:
Already upstream.
> apr-1.0.0-mutextype_reorder.diff:
Unnecessary. If you want to target 2.4.x kernels then build on 2.4.x,
otherwise you can force the order using cache variables, no patching
necessary.
> apr-1.1.0-config.diff:
Current upstream code is OK, not really needed.
> apr-util-0.9.5-lib64.diff:
Better fix needed, won't commit as-is per past discussion/bugzilla.
> apr-util-1.2.2-config.diff:
Current upstream code is OK, not really needed.
> apr-util-1.2.2-postgresql.diff:
If you make the test conditional and re-submit it this looks like it is
needed.
joe
Re: buildconf against installed APR
Posted by Oden Eriksson <oe...@mandriva.com>.
fredagen den 2 december 2005 09.15 skrev Paul Querna:
> Oden Eriksson wrote:
> > torsdagen den 1 december 2005 23.56 skrev Sander Temme:
> >> On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote:
> >>> torsdagen den 1 december 2005 21.38 skrev Sander Temme:
> >>>> Note the cp turds: those files are not installed along with APR, so
> >>>> buildconf cannot copy them over. How come I or no one else noticed
> >>>> this ever? Probably because these files are not cleaned up by make
> >>>
> >>> Because you never package it like we do. I think you only do ./
> >>> configure;
> >>> make; make install and are satisfied with that.
> >>
> >> Oden,
> >>
> >> Can you tell us what steps you take to package httpd/apr/apr-util? I
> >> think that would tell us a little more about possible use cases for
> >> the build system.
> >>
> >> Thanks,
> >>
> >> S.
> >
> > Ok, will do.
> >
> > I publish the rpm spec files and I hope it won't be hard to understand
> > them.
> >
> > Here are the spec files:
> >
> > http://nux.se/Cooker/SPECS/
> >
> > And here are source and patches applied:
> >
> > http://nux.se/Cooker/SOURCES/
>
> It would be good to merge in as many patches as possible that you apply
> to our code base.. external patches are not good for anyone.
>
> -Paul
OK.
apr-0.9.3-deplibs.patch:
- link libapr against libraries on which it depends
- re-order link line so that -pthread can be passed down to the
compiler driver with an appropriate LT_LDFLAGS
Author: Joe Orton
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/apr-0.9.3-deplibs.patch
apr-1.0.0-mutextype_reorder.diff:
This one makes the mutext type set as default to fcntl because the
implementation in the nptl in recent linux distros seems very
unmature/unstable, especially if you use exotic CPU's (that does not present
themselves as a i686 i think) and kernel 2.4.x with apr compiled on a Linux
2.6.x box against nptl. Well I guess that is Linux specific and won't make it
into your codebase. Anyway it saves a lot of headaches...
Author: Oden Eriksson
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/apr-1.0.0-mutextype_reorder.diff
apr-1.1.0-config.diff:
Removes not needed code from arp-config
Author: Joe Orton
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/apr-1.1.0-config.diff
apr-util-0.9.5-lib64.diff:
- shuffle the find libname logic around a bit.
In all the autofoo and m4 macros "/lib" is hardcoded, that should be fixed. I
see now php has finally fixed it like this "--with-libdir=libfoo", maybe you
can do it like that too?
Author: Oden Eriksson
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/apr-util-0.9.5-lib64.diff
apr-util-1.2.2-config.diff:
Removes not needed code from arp-config
Author: Joe Orton
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/apr-util-1.2.2-config.diff
apr-util-1.2.2-postgresql.diff:
This is needed in Mandriva, and possible in other distros too. It should be
another test added.
Author: Oden Eriksson
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/apr-util-1.2.2-postgresql.diff
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
Re: buildconf against installed APR
Posted by Oden Eriksson <oe...@mandriva.com>.
fredagen den 2 december 2005 02.54 skrev Oden Eriksson:
> torsdagen den 1 december 2005 23.56 skrev Sander Temme:
> > On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote:
> > > torsdagen den 1 december 2005 21.38 skrev Sander Temme:
> > >> Note the cp turds: those files are not installed along with APR, so
> > >> buildconf cannot copy them over. How come I or no one else noticed
> > >> this ever? Probably because these files are not cleaned up by make
> > >
> > > Because you never package it like we do. I think you only do ./
> > > configure;
> > > make; make install and are satisfied with that.
> >
> > Oden,
> >
> > Can you tell us what steps you take to package httpd/apr/apr-util? I
> > think that would tell us a little more about possible use cases for
> > the build system.
> >
> > Thanks,
> >
> > S.
>
> Ok, will do.
>
> I publish the rpm spec files and I hope it won't be hard to understand
> them.
>
> Here are the spec files:
>
> http://nux.se/Cooker/SPECS/
>
> And here are source and patches applied:
>
> http://nux.se/Cooker/SOURCES/
Ahh, I'm tired, I should have pointed in the right direction:
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/
:-)
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
Re: buildconf against installed APR
Posted by Paul Querna <ch...@force-elite.com>.
Oden Eriksson wrote:
> torsdagen den 1 december 2005 23.56 skrev Sander Temme:
>
>> On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote:
>>
>>> torsdagen den 1 december 2005 21.38 skrev Sander Temme:
>>>
>>>> Note the cp turds: those files are not installed along with APR, so
>>>> buildconf cannot copy them over. How come I or no one else noticed
>>>> this ever? Probably because these files are not cleaned up by make
>>>>
>>> Because you never package it like we do. I think you only do ./
>>> configure;
>>> make; make install and are satisfied with that.
>>>
>> Oden,
>>
>> Can you tell us what steps you take to package httpd/apr/apr-util? I
>> think that would tell us a little more about possible use cases for
>> the build system.
>>
>> Thanks,
>>
>> S.
>>
>
> Ok, will do.
>
> I publish the rpm spec files and I hope it won't be hard to understand them.
>
> Here are the spec files:
>
> http://nux.se/Cooker/SPECS/
>
> And here are source and patches applied:
>
> http://nux.se/Cooker/SOURCES/
>
>
It would be good to merge in as many patches as possible that you apply
to our code base.. external patches are not good for anyone.
-Paul
Re: buildconf against installed APR
Posted by Graham Leggett <mi...@sharp.fm>.
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
> 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
--
Re: buildconf against installed APR
Posted by Luc Pardon <lu...@skopos.be>.
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
Re: buildconf against installed APR
Posted by Graham Leggett <mi...@sharp.fm>.
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.
> 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).
Regards,
Graham
--
Re: buildconf against installed APR
Posted by Luc Pardon <lu...@skopos.be>.
> 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
Re: buildconf against installed APR
Posted by Graham Leggett <mi...@sharp.fm>.
Oden Eriksson wrote:
> I publish the rpm spec files and I hope it won't be hard to understand them.
>
> Here are the spec files:
>
> http://nux.se/Cooker/SPECS/
>
> And here are source and patches applied:
>
> http://nux.se/Cooker/SOURCES/
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, and the httpd one depends on apr-1.x.
If you look at these files (httpd.spec/apr.spec in the root of the
tarball) it should give you an example to work from of how to get apr to
play nice with httpd.
Regards,
Graham
--
Re: buildconf against installed APR
Posted by Oden Eriksson <oe...@mandriva.com>.
torsdagen den 1 december 2005 23.56 skrev Sander Temme:
> On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote:
> > torsdagen den 1 december 2005 21.38 skrev Sander Temme:
> >> Note the cp turds: those files are not installed along with APR, so
> >> buildconf cannot copy them over. How come I or no one else noticed
> >> this ever? Probably because these files are not cleaned up by make
> >
> > Because you never package it like we do. I think you only do ./
> > configure;
> > make; make install and are satisfied with that.
>
> Oden,
>
> Can you tell us what steps you take to package httpd/apr/apr-util? I
> think that would tell us a little more about possible use cases for
> the build system.
>
> Thanks,
>
> S.
Ok, will do.
I publish the rpm spec files and I hope it won't be hard to understand them.
Here are the spec files:
http://nux.se/Cooker/SPECS/
And here are source and patches applied:
http://nux.se/Cooker/SOURCES/
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
Re: buildconf against installed APR
Posted by Sander Temme <sa...@temme.net>.
On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote:
> torsdagen den 1 december 2005 21.38 skrev Sander Temme:
>
>> Note the cp turds: those files are not installed along with APR, so
>> buildconf cannot copy them over. How come I or no one else noticed
>> this ever? Probably because these files are not cleaned up by make
>
> Because you never package it like we do. I think you only do ./
> configure;
> make; make install and are satisfied with that.
Oden,
Can you tell us what steps you take to package httpd/apr/apr-util? I
think that would tell us a little more about possible use cases for
the build system.
Thanks,
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: buildconf against installed APR
Posted by Oden Eriksson <oe...@mandriva.com>.
torsdagen den 1 december 2005 21.38 skrev Sander Temme:
> Note the cp turds: those files are not installed along with APR, so
> buildconf cannot copy them over. How come I or no one else noticed
> this ever? Probably because these files are not cleaned up by make
Because you never package it like we do. I think you only do ./configure;
make; make install and are satisfied with that.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se