Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0CA319A49 for ; Wed, 1 Feb 2012 00:02:20 +0000 (UTC) Received: (qmail 44388 invoked by uid 500); 1 Feb 2012 00:02:19 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 44319 invoked by uid 500); 1 Feb 2012 00:02:18 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 44310 invoked by uid 99); 1 Feb 2012 00:02:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 00:02:17 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of noel.butler@ausics.net designates 27.33.160.23 as permitted sender) Received: from [27.33.160.23] (HELO valhalla.ausics.net) (27.33.160.23) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 00:02:11 +0000 Received: from [10.10.0.145] (tardis.ausics.net [10.10.0.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by valhalla.ausics.net (Postfix) with ESMTPSA id 13B45C0E156 for ; Wed, 1 Feb 2012 10:01:47 +1000 (EST) Subject: Re: documenting -deps From: Noel Butler To: dev@httpd.apache.org In-Reply-To: References: <4F15D6EE.4000403@rowe-clan.net> <4F15DAF2.8060803@gknw.net> <67B9D7DB-F25A-4839-BE79-F86966C0126B@jaguNET.com> <4F281F07.4000106@rowe-clan.net> <9D6EA405-EC6E-4E16-9703-73E7300FBBA0@jaguNET.com> <4F282A03.4040905@rowe-clan.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-oQHKjEEoe3DRGDWeK0oK" Date: Wed, 01 Feb 2012 10:01:46 +1000 Message-ID: <1328054506.6130.21.camel@tardis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 --=-oQHKjEEoe3DRGDWeK0oK Content-Type: multipart/alternative; boundary="=-frxIdobHdSCLR5NxckdB" --=-frxIdobHdSCLR5NxckdB Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Tue, 2012-01-31 at 14:40 -0500, Jim Jagielski wrote: > The release is a snapshot of time. All we are saying if > we bundle apr/apu (in whatever fashion) is that at the > time we are releasing httpd, here are the additional > ASF packages (apr/apu) that we're providing to you, the > end user, for your convenience. We are free to call that > package whatever the heck we want. >=20 > There's really no reason to make this more difficult than > it is... I am sure that when we make windows builds, it is > quite possible that we are "bundling" things in there which, > by your argument, implies forcing the windows builder here > to rebuild it to capture updates. >=20 > I for one don't care whether we do or not, but I think that > it's a topic for discussion; other may think it's a nice thing > to do. And if the concern against it is something that is easily > fixed, then that is also a good thing to know. >=20 Given in the *nix version, the -deps package only contains apr/apr-util, I think it would be a better idea to=20 call it httpd...-aprutils as you earlier suggested, and maybe for the 2.4.1 release. Else someone who builds using OS distro pre-installed version of APR and not "included", may think they need this file as well when its clear they don't. As for complete removal, I think it's a bad idea, but... might I suggest that if majority decides to remove it entirely, that - =20 1/ Warnings indicating so be put in the relevant README/INSTALL files, and 2/ It be kept for the life of 2.4, and removed in 2.(5|6) 3/ The -deps/aprutils file gets it own brief README file warning that it will be removed as of next major release, and those wanting to use current "best" APR/APRU, will need to get it from This way, no one can say they were not warned, you may be surprised at the number of admins that do build with included APR and not the OS distro's (usually very antiquated) installed version. I for one, know of only two that use OS vendors supplied package, but many more that use included from source packages, yes, there really is a lot of people out there that do not use vendor specific installs for either httpd or apr, because as we all know, in particular for the former, they are not, and can never be, built for every possible scenario. my 2c worth. --=-frxIdobHdSCLR5NxckdB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-01-31 at 14:40 -0500, Jim Jagielski wrote:

The release is a snapshot of time. All we are saying if
we bundle apr/apu (in whatever fashion) is that at the
time we are releasing httpd, here are the additional
ASF packages (apr/apu) that we're providing to you, the
end user, for your convenience. We are free to call that
package whatever the heck we want.

There's really no reason to make this more difficult than
it is... I am sure that when we make windows builds, it is
quite possible that we are "bundling" things in there which,
by your argument, implies forcing the windows builder here
to rebuild it to capture updates.

I for one don't care whether we do or not, but I think that
it's a topic for discussion; other may think it's a nice thing
to do. And if the concern against it is something that is easily
fixed, then that is also a good thing to know.

Given in the *nix version, the -deps package only contains apr/apr-util,&nb= sp;  I think it would be a better idea to
call it httpd...-aprutils  as you earlier suggested, and maybe for the= 2.4.1 release.

Else someone who builds using OS distro pre-installed version of APR and no= t "included", may think they need this file as well when its clea= r they don't.

As for complete removal, I think it's a bad idea, but... might I suggest th= at if majority decides to remove it entirely, that -  
          1/  Warnings in= dicating so be put in the relevant README/INSTALL files, and
          2/  It be kept = for the life of 2.4, and removed in 2.(5|6)
          3/  The -deps/a= prutils file gets it own brief README file warning that it will be removed = as of next major release, and those   wanting to use current &quo= t;best" APR/APRU, will need to get it from <insert-apr-URL>

This way, no one can say they were not warned, you may be surprised at the = number of admins that do build with included APR and not the OS distro's (u= sually very antiquated) installed version.

I for one, know of only two that use OS vendors supplied package, but many= more that use included from source packages, yes, there really is a lot of= people out there that do not use vendor specific installs for either httpd= or apr, because as we all know, in particular for the former, they are not= , and can never be, built for every possible scenario.

my 2c worth.

--=-frxIdobHdSCLR5NxckdB-- --=-oQHKjEEoe3DRGDWeK0oK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJPKIDlAAoJECg/hgl/0DbH0qwH/0Zib1tqW3X6pFANdGbxOeYV iyT3/b6ipK/zNVpGHb0iOoOSt3nXz7XHlRzONSXX6khC3wP1ebRS7YuKNaglIPXS DkZ16HO8+yCuJZO3ulkVtjQK9fZJDvNnr1GP1lXtzdQ7lbeY7Y26q2hOlNDH+kQe Vz8mfiKD/pIJph7unRkh58hZETcYQyrJcyB1vWm04O+Sa0rHhRCjVt69J0NK1V0y ypLzEVdKufMrU70BHuqv3kVuEUiIfJFWZTpv2NT2tTndDGhGGHL/v/z/BOnjwBwg eb0vcenbcKdU8w5Q/KHfaX7n/Ob1pt1j/i0OIF4HKGp/qcp4wedGV+cl+Kx+sME= =m1Gf -----END PGP SIGNATURE----- --=-oQHKjEEoe3DRGDWeK0oK--