Upgrade Apache2 port from 2.0.35 to 2.0.36. How-To-Repeat: N/A
Responsible Changed From-To: freebsd-ports->cy I opened it, I'll work with the maintainer.
State Changed From-To: open->suspended Received the following email from Hye-Shik Chang <perky@fallin.lv>, maintainer of apache2: Thank you very much. BTW, Garrett Rooney <rooneg@electricjellyfish.net>, the port maintainer of devel/apr-devel want to split up apache2 and apr. (apr-devel port conflicts with apache2 now.) I'll send you a patch after splitting them if you can help to commit it.)
(added gnats-submit@ and cy@FreeBSD.org on CC) On Wed, May 08, 2002 at 12:20:55AM -0400, Garrett Rooney wrote: > On Wed, May 08, 2002 at 12:42:40PM +0900, Hye-Shik Chang wrote: > > On Tue, May 07, 2002 at 10:52:18PM -0400, Garrett Rooney wrote: > > > > third, if you're really really feeling ambitios, how would you feel > > about making apache2 use the version of apr from the ports tree, > > rather than it's internal version? it might be a bit of a pain for > > now, but eventually, apr will have a release version, and it would be > > nice to get both subversion and apache2 using it. > > Ok. Ben Gross <ben@bengross.com> suggested me splitting up apache and apr. > but I thought Apache 2.0.28 wasn't stable enough to split its core libraries. > but it is okay now. I'll work for it in no time. hmm. I found that apr_20020504162319 and apr-util_20020504162319 have some newer codes than httpd-2.0.36. because Apache group doesn't released apr-20020504162319 in general availability, it can be a problem if we link apache2 port with apr-devel-20020504162319. which one would be better: 1. create devel/apr port with httpd-2.0.36.tar.gz 2. put a rollback patch into apr-devel with apr-20020504162319 and httpd-2.0.36 3. enforce apache2 port to use apr-devel 20020504162319 4. leave apache2 port alone. 5. more opinion? Regards, -- Hye-Shik Chang <perky@fallin.lv> Yonsei University, Seoul ^D
On Wed, May 08, 2002 at 01:53:57PM +0900, Hye-Shik Chang wrote: > (added gnats-submit@ and cy@FreeBSD.org on CC) > > On Wed, May 08, 2002 at 12:20:55AM -0400, Garrett Rooney wrote: > > On Wed, May 08, 2002 at 12:42:40PM +0900, Hye-Shik Chang wrote: > > > On Tue, May 07, 2002 at 10:52:18PM -0400, Garrett Rooney wrote: > > > > > > third, if you're really really feeling ambitios, how would you feel > > > about making apache2 use the version of apr from the ports tree, > > > rather than it's internal version? it might be a bit of a pain for > > > now, but eventually, apr will have a release version, and it would be > > > nice to get both subversion and apache2 using it. > > > > Ok. Ben Gross <ben@bengross.com> suggested me splitting up apache and apr. > > but I thought Apache 2.0.28 wasn't stable enough to split its core libraries. > > but it is okay now. I'll work for it in no time. > > hmm. I found that apr_20020504162319 and apr-util_20020504162319 have some newer > codes than httpd-2.0.36. because Apache group doesn't released apr-20020504162319 > in general availability, it can be a problem if we link apache2 port with > apr-devel-20020504162319. > > which one would be better: > > 1. create devel/apr port with httpd-2.0.36.tar.gz this is certainly an option. in the long run, i want to do this anyway, but i was hoping to wait until an sctual stable release of apr. having two versions of apr from ports, one required by subversion and one required by apache2 is basically just the same situation we've got now, since apache2 is doing that anyway. so i guess i'd say this is where i want to go in the future, but not quite yet. > 2. put a rollback patch into apr-devel with apr-20020504162319 and httpd-2.0.36 > 3. enforce apache2 port to use apr-devel 20020504162319 how extensive a patch would be required to make apache2 use the version of apr-devel in the ports tree? if it's fairly simple, i'd say go with this solution. i'd hope that apr is stabalizing at this point so that this will be the last time that an update to it will be source incompatable with older versions. > 4. leave apache2 port alone. i'm almost leaning towards this point... if it takes more than some trivial changes to make apache2 work with the current version of apr-devel, i'd say just leave things alone until the next release of apache, when hopefully things will be in synch more. thanks, -garrett -- garrett rooney Remember, any design flaw you're rooneg@electricjellyfish.net sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski
In message <20020508123850.GC85290@electricjellyfish.net>, Garrett Rooney write s: > On Wed, May 08, 2002 at 01:53:57PM +0900, Hye-Shik Chang wrote: > > (added gnats-submit@ and cy@FreeBSD.org on CC) > > > > On Wed, May 08, 2002 at 12:20:55AM -0400, Garrett Rooney wrote: > > > On Wed, May 08, 2002 at 12:42:40PM +0900, Hye-Shik Chang wrote: > > > > On Tue, May 07, 2002 at 10:52:18PM -0400, Garrett Rooney wrote: > > > > > > > > third, if you're really really feeling ambitios, how would you feel > > > > about making apache2 use the version of apr from the ports tree, > > > > rather than it's internal version? it might be a bit of a pain for > > > > now, but eventually, apr will have a release version, and it would be > > > > nice to get both subversion and apache2 using it. > > > > > > Ok. Ben Gross <ben@bengross.com> suggested me splitting up apache and apr > . > > > but I thought Apache 2.0.28 wasn't stable enough to split its core librar > ies. > > > but it is okay now. I'll work for it in no time. > > > > hmm. I found that apr_20020504162319 and apr-util_20020504162319 have some > newer > > codes than httpd-2.0.36. because Apache group doesn't released apr-20020504 > 162319 > > in general availability, it can be a problem if we link apache2 port with > > apr-devel-20020504162319. > > > > which one would be better: > > > > 1. create devel/apr port with httpd-2.0.36.tar.gz > > this is certainly an option. in the long run, i want to do this > anyway, but i was hoping to wait until an sctual stable release of > apr. having two versions of apr from ports, one required by > subversion and one required by apache2 is basically just the same > situation we've got now, since apache2 is doing that anyway. > > so i guess i'd say this is where i want to go in the future, but not > quite yet. I think that this is a wise option. I think we should hold of on this until we have shaken out any bugs introduced by the "split". > > > 2. put a rollback patch into apr-devel with apr-20020504162319 and httpd-2 > .0.36 > > 3. enforce apache2 port to use apr-devel 20020504162319 > > how extensive a patch would be required to make apache2 use the > version of apr-devel in the ports tree? if it's fairly simple, i'd > say go with this solution. i'd hope that apr is stabalizing at this > point so that this will be the last time that an update to it will be > source incompatable with older versions. I think that this is too aggressive. > > > 4. leave apache2 port alone. > > i'm almost leaning towards this point... > > if it takes more than some trivial changes to make apache2 work with > the current version of apr-devel, i'd say just leave things alone > until the next release of apache, when hopefully things will be in > synch more. I think we should apply my patch to upgrade to 2.0.36 for now and continue to work on the "split". Once we implement the "split" I think that the apache2 port should, for a short while after the split, have the option of implementing functions and libraries that come with apache2 just in case we've introduced a bug that is a show stopper for someone: Our response would be rebuild apache2 with -DOLD_STYLE. Once we're completely happy with the "split", we can remove the OLD_STYLE option. This will require additional development and maintenance effort but is the more conservative approach. Alternatively we could create an apache2-split port with the intention of removing apache2 at some future date. There may be some who may not like the ideas I've presented here so discussing this on -ports prior to choosing an implementation approach would probably help. Thoughts? Please let me know if I can go ahead and commit my patch in the interim. Cheers, Phone: 250-387-8437 Cy Schubert Fax: 250-387-5766 Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: cy@FreeBSD.org
On Wed, May 08, 2002 at 08:35:38AM -0700, Cy Schubert - CITS Open Systems Group wrote: > > > 1. create devel/apr port with httpd-2.0.36.tar.gz > > > > this is certainly an option. in the long run, i want to do this > > anyway, but i was hoping to wait until an sctual stable release of > > apr. having two versions of apr from ports, one required by > > subversion and one required by apache2 is basically just the same > > situation we've got now, since apache2 is doing that anyway. > > > > so i guess i'd say this is where i want to go in the future, but not > > quite yet. > > I think that this is a wise option. I think we should hold of on this > until we have shaken out any bugs introduced by the "split". i am in total agreement. > > > 2. put a rollback patch into apr-devel with apr-20020504162319 and httpd-2 > > .0.36 > > > 3. enforce apache2 port to use apr-devel 20020504162319 > > > > how extensive a patch would be required to make apache2 use the > > version of apr-devel in the ports tree? if it's fairly simple, i'd > > say go with this solution. i'd hope that apr is stabalizing at this > > point so that this will be the last time that an update to it will be > > source incompatable with older versions. > > I think that this is too aggressive. you are probably correct. > > > 4. leave apache2 port alone. > > > > i'm almost leaning towards this point... > > > > if it takes more than some trivial changes to make apache2 work with > > the current version of apr-devel, i'd say just leave things alone > > until the next release of apache, when hopefully things will be in > > synch more. > > I think we should apply my patch to upgrade to 2.0.36 for now and > continue to work on the "split". this seems like the best short term plan. i think i can modify the subversion port to use either the version of apr from devel/apr-devel or the version from www/apache2, depending on what is installed, which will eliminate most of the complaints people have had. > Once we implement the "split" I think that the apache2 port should, for > a short while after the split, have the option of implementing > functions and libraries that come with apache2 just in case we've > introduced a bug that is a show stopper for someone: Our response > would be rebuild apache2 with -DOLD_STYLE. Once we're completely happy > with the "split", we can remove the OLD_STYLE option. This will > require additional development and maintenance effort but is the more > conservative approach. Alternatively we could create an apache2-split > port with the intention of removing apache2 at some future date. There > may be some who may not like the ideas I've presented here so > discussing this on -ports prior to choosing an implementation approach > would probably help. i would feel most comfortable with using a 'WITH_BUNDLED_APR' option that would force the use of the version of apr/apr-util that is bundled with apache2, and if that isn't defined, use the version of apr from ports. while we're working out the bugs, we can just define 'WITH_BUNDLED_APR', and when we're comfortable with the status, we can throw the switch. it seems like a separate 'apache2-split' port is overkill, unless it turns out that an option in the main port is simply too much work. i mean come on, the apache people went to a lot of trouble splitting things out into a separate portability library, so i think it's the least we can do to try and make it work the way (in my opnion) it was intended to work. personally, my current favorite plan is this: 1) commit Cy's version of the port so people can have an up to date version. 2) figure out what, if anything, needs to be done to make the port use the version of expat we have in ports rather than the version they bundle. this becomes important when other apps try to use apr, because when you build with an internal expat, the output of apu-config becomes useless for some things. 3) start the process of providing a 'WITH_BUNDLED_APR' knob, turned on (meaning using the internal version of apr by default) at first, and then when we're fine with it, turned off by default. thanks, -garrett -- rooneg@electricjellyfish.net sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski
hmm. let's update it unsplitted for the moment, and how about open new PR on splitting or WITH_BUNDLED_APR option, Garrett? Please commit your patch with my some additional patches, Cy. ;) On Tue, May 07, 2002 at 10:52:18PM -0400, Garrett Rooney wrote: > second, how would you feel about removing the patches that make the in > tree version of apr-util avoid looking in /usr and /usr/local for > expat, and just use the expat2 port? if you use the in tree expat, linking with localbase's expat generates too many dependencies. I'd like to make WITHOUT_BUNDLED_EXPAT option. what do you think? diff -ruN apache2.cy/Makefile apache2/Makefile --- apache2.cy/Makefile Wed May 8 19:36:27 2002 +++ apache2/Makefile Thu May 9 00:38:49 2002 @@ -41,7 +41,7 @@ SHARED_MODULES= all cgid charset_lite ext_filter case_filter case_filter_in \ deflate bucketeer RC_SUB= -e 's,@@PREFIX@@,${PREFIX},g' -e 's,@@DESTDIR@@,${DESTDIR},g' -MAKE_ENV+= DESTDIR=${DESTDIR} +MAKE_ENV+= DESTDIR=${DESTDIR} EXPR_COMPAT=yes PLIST_SUB+= DESTDIR=${DESTDIR} .if defined(NOPORTDOCS) @@ -114,13 +114,6 @@ @${FIND} ${WRKSRC} -name "*.orig" -exec ${RM} -f {} \; @${SED} ${RC_SUB} ${FILESDIR}/apache.sh >${WRKDIR}/apache2.sh @${SED} ${RC_SUB} ${FILESDIR}/config.layout >>${WRKSRC}/config.layout -.if ${OSVERSION} >= 500032 -.for ltfile in srclib/pcre/ltmain.sh srclib/apr/build/ltmain.sh \ - srclib/apr-util/xml/expat/conftools/ltmain.sh - @${PERL} -pi.orig -e 's|expr|expr --|' \ - ${WRKSRC}/${ltfile} -.endfor -.endif pre-install: PKG_PREFIX=${PREFIX} ${SH} pkg-install ${PKGNAME} PRE-INSTALL @@ -130,7 +123,7 @@ ${ECHO} "Installing ${PREFIX}/etc/rc.d/apache2.sh startup file."; \ ${INSTALL_SCRIPT} -m 751 ${WRKDIR}/apache2.sh ${PREFIX}/etc/rc.d/apache2.sh; \ fi - [ -d ${DESTDIR}/var/log ] || ${MKDIR} ${DESTDIR}/var/log - [ -d ${DESTDIR}/var/run ] || ${MKDIR} ${DESTDIR}/var/run + @[ -d ${DESTDIR}/var/log ] || ${MKDIR} ${DESTDIR}/var/log + @[ -d ${DESTDIR}/var/run ] || ${MKDIR} ${DESTDIR}/var/run .include <bsd.port.post.mk> diff -ruN apache2.cy/files/patch-configure apache2/files/patch-configure --- apache2.cy/files/patch-configure Wed May 8 19:36:38 2002 +++ apache2/files/patch-configure Wed May 8 19:53:09 2002 @@ -1,5 +1,14 @@ ---- configure.orig Wed May 1 13:53:00 2002 -+++ configure Tue May 7 19:28:57 2002 +--- configure.orig Thu May 2 05:53:00 2002 ++++ configure Wed May 8 16:12:46 2002 +@@ -1503,7 +1503,7 @@ + $srcdir/config.layout > $pldconf + layout_name=$LAYOUT + . $pldconf +- rm $pldconf ++ rm -f $pldconf + for var in prefix exec_prefix bindir sbindir libexecdir mandir \ + sysconfdir datadir errordir iconsdir htdocsdir cgidir \ + includedir localstatedir runtimedir logfiledir libdir \ @@ -15077,6 +15077,9 @@ cat >>confdefs.h <<_ACEOF diff -ruN apache2.cy/files/patch-support:apxs.in apache2/files/patch-support:apxs.in --- apache2.cy/files/patch-support:apxs.in Tue Apr 9 00:57:07 2002 +++ apache2/files/patch-support:apxs.in Wed May 8 19:53:09 2002 @@ -1,5 +1,5 @@ ---- support/apxs.in.orig Thu Mar 14 05:48:05 2002 -+++ support/apxs.in Sun Apr 7 08:47:34 2002 +--- support/apxs.in.orig Tue Apr 30 03:09:02 2002 ++++ support/apxs.in Wed May 8 19:41:06 2002 @@ -66,7 +66,7 @@ # read the configuration variables once @@ -9,7 +9,16 @@ my $exec_prefix = get_vars("exec_prefix"); my $CFG_TARGET = get_vars("progname"); -@@ -415,7 +415,7 @@ +@@ -223,7 +223,7 @@ + my $httpd = get_vars("sbindir") . "/" . get_vars("progname"); + $httpd = eval qq("$httpd"); + $httpd = eval qq("$httpd"); +-my $envvars = get_vars("bindir") . "/envvars"; ++my $envvars = get_vars("sbindir") . "/envvars"; + $envvars = eval qq("$envvars"); + $envvars = eval qq("$envvars"); + +@@ -418,7 +418,7 @@ $la =~ s|\.c$|.la|; my $o = $s; $o =~ s|\.c$|.o|; @@ -18,7 +27,7 @@ unshift(@objs, $lo); } -@@ -440,7 +440,7 @@ +@@ -443,7 +443,7 @@ $opt .= " -l$opt_l"; } @@ -27,7 +36,7 @@ # execute the commands &execute_cmds(@cmds); -@@ -471,8 +471,8 @@ +@@ -474,8 +474,8 @@ $t =~ s|^.+/([^/]+)$|$1|; $t =~ s|\.la$|\.so|; if ($opt_i) { -- Hye-Shik Chang <perky@fallin.lv> Yonsei University, Seoul ^D
On Thu, May 09, 2002 at 01:04:14AM +0900, Hye-Shik Chang wrote: > hmm. let's update it unsplitted for the moment, > and how about open new PR on splitting or WITH_BUNDLED_APR option, Garrett? > Please commit your patch with my some additional patches, Cy. ;) i will open up a pr about it soon. > On Tue, May 07, 2002 at 10:52:18PM -0400, Garrett Rooney wrote: > > second, how would you feel about removing the patches that make the in > > tree version of apr-util avoid looking in /usr and /usr/local for > > expat, and just use the expat2 port? if you use the in tree expat, > > linking with localbase's expat generates too many dependencies. > I'd like to make WITHOUT_BUNDLED_EXPAT option. what do you think? what dependencies are you talking about? ports/textproc/expat2 depends on libtool and gmake for building, but that's it as far as i can see. personally, i would much prefer defaulting to using the localbase expat, if only because it makes the apache2 port a better citizen of the ports tree. having multuple copies of the same library lying around just doesn't seem right. -garrett -- garrett rooney Remember, any design flaw you're rooneg@electricjellyfish.net sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski
In message <20020508160414.GA84998@fallin.lv>, Hye-Shik Chang writes: > hmm. let's update it unsplitted for the moment, > and how about open new PR on splitting or WITH_BUNDLED_APR option, Garrett? Good plan. > Please commit your patch with my some additional patches, Cy. ;) The patch looks good. > > On Tue, May 07, 2002 at 10:52:18PM -0400, Garrett Rooney wrote: > > second, how would you feel about removing the patches that make the in > > tree version of apr-util avoid looking in /usr and /usr/local for > > expat, and just use the expat2 port? if you use the in tree expat, > > linking with localbase's expat generates too many dependencies. > I'd like to make WITHOUT_BUNDLED_EXPAT option. what do you think? Sounds OK. [patch removed] Cheers, Phone: 250-387-8437 Cy Schubert Fax: 250-387-5766 Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: cy@FreeBSD.org
State Changed From-To: suspended->closed Upgrade committed. Thanks to all who contributed.