Re: apr-config and apr-1-config
At 04:55 PM 7/1/2004, Joe Orton wrote: On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote: Joe Orton wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment. How do you suggest the RPM should handle this? - at the moment installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. Should we just leave it as is for now? Yes, just leave it for the moment I guess. If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( Bill
Re: apr-config and apr-1-config
On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: At 04:55 PM 7/1/2004, Joe Orton wrote: On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote: Joe Orton wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment. How do you suggest the RPM should handle this? - at the moment installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. Should we just leave it as is for now? Yes, just leave it for the moment I guess. If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? -- Greg Stein, http://www.lyra.org/
Re: apr-config and apr-1-config
At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Bill Bill
Re: apr-config and apr-1-config
At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Well, some form of explanation of the above would be more helpful than cryptic comments. 1/10 on helpfulness. david
Re: apr-config and apr-1-config
David Reid [EMAIL PROTECTED] writes: [...] Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... The s/apr-config/apr-1-config/ is certainly going to generate extra work for apr applications that currently build fine with either 0.9 or HEAD. For example apxs and all apxs-dependent apache modules that want to support httpd-2.2 will need to use something better than APR_CONFIG=`$APXS -q APR_BINDIR`/apr-config However, IMO it's absolutely worth the extra effort because the name change will guarantee httpd-2.0's apxs still supplies such modules with the right apr lib. -- Joe Schaefer
Re: apr-config and apr-1-config
On Fri, 2004-07-02 at 12:52 -0400, Joe Schaefer wrote: David Reid [EMAIL PROTECTED] writes: [...] Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... The s/apr-config/apr-1-config/ is certainly going to generate extra work for apr applications that currently build fine with either 0.9 or HEAD. For example apxs and all apxs-dependent apache modules that want to support httpd-2.2 will need to use something better than APR_CONFIG=`$APXS -q APR_BINDIR`/apr-config However, IMO it's absolutely worth the extra effort because the name change will guarantee httpd-2.0's apxs still supplies such modules with the right apr lib. This is a separate issue for APXS. It needs another -q item added in 2.1 telling us the name of the binary, not just the directory. (to allow a parallel install of APR, and possibly httpd-2.0/2.1) -Paul Querna
Re: apr-config and apr-1-config
At 11:20 AM 7/2/2004, you wrote: At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... Speed/Schedule of releasing 1.0 v.s. Completeness/Interoperability w/ 0.9. I for one am glad you've put folks feet to the fire so to speak, and laid out an ambitious plan for release of 1.0 this month :) Sometimes, until you try to implement, what seemed just fine in a build system turns out to be ineffective when confronted with rolling usable rpm's, deploying side by side with previous versions, etc. It wasn't until apr-1.0 that the apr/httpd side has ever really considered side-by-side installation issues, since we need the legacy 0.9 for some time to support httpd 2.0, and will need 1.0 installed and ready for httpd 2.1+, svn, jakarta-jk2 and so forth. Graham's RPM efforts have put a magnifying glass to every open parallel install issue - I think it's wonderful that he created the perfect example case whether he intended to, or not :) who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Well, some form of explanation of the above would be more helpful than cryptic comments. Sorry, it was my reaction to Greg's comments - which read (to me) that he was saying yes - table this for now, release 1.0.0, install and clobber the existing shared apr 0.9.5 install, then figure out how to get it right with release 1.0.1. That concerned me. 1/10 on helpfulness. I believe, with the possible exception of apr_finfo_t::ctime (and still asking for feedback), that APR is code-complete API stable for 1.0. With apr-iconv designated as a mutable implementation detail of the public apr_xlate interface, that is not an issue either. I spent no time in apr-util so I really don't have an opinion either way. If Graham's efforts, with Joe's useful feedback, produces a build system which cleanly lets 0.9 and 1.0 (and future releases) coexist, I'm satisfied we finished APR 1.0. I'd be very happy if we left apr-config alone (as 0.9), created apr-1-config or apr-1.0-config with a symlink named apr-1-config, and let the consumers attempt to use apr-[n..1]-config down to apr-config, based on what THEIR application is targeted at and capable of supporting. The version argument solution to apr-config also sounds like it could solve the problem. Bill
Re: apr-config and apr-1-config
William A. Rowe, Jr. wrote: If Graham's efforts, with Joe's useful feedback, produces a build system which cleanly lets 0.9 and 1.0 (and future releases) coexist, I'm satisfied we finished APR 1.0. I've just tried to install an RPM of httpd 2.0.50 onto a system that already has RPMs of apr-1.0.0 and apr-util-1.0.0 installed, and the httpd RPM installs cleanly with no conflicts. The httpd RPM contains httpd + apr-0.9 + apr-util-0.9 rolled up into a single RPM. A further question though - is it worth making the effort to make RPMs for apr (and apr-util) v0.9, or is it sufficient to leave it as it is now: httpd v2.0.x includes a rolled up version of apr v0.9 in a single package. In other words, what other projects apart from httpd are using apr v0.9 and not apr v1.0? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
apr-config and apr-1-config
Hi all, I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-config and apr-1-config
On Thu, Jul 01, 2004 at 11:10:25PM +0200, Graham Leggett wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment.
Re: apr-config and apr-1-config
Joe Orton wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment. How do you suggest the RPM should handle this? - at the moment installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. Should we just leave it as is for now? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-config and apr-1-config
On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote: Joe Orton wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment. How do you suggest the RPM should handle this? - at the moment installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. Should we just leave it as is for now? Yes, just leave it for the moment I guess. joe
