Re: buildconf against installed APR
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
Re: buildconf against installed APR
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
Re: buildconf against installed APR
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 -- smime.p7s Description: S/MIME Cryptographic Signature
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
echosvn 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
echosvn 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:
[EMAIL PROTECTED] 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
Re: buildconf against installed APR
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
Re: buildconf against installed APR
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. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: buildconf against installed APR
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
