On 12/21/2010 9:34 AM, Jim Jagielski wrote:
>
> On Dec 21, 2010, at 9:19 AM, Jim Jagielski wrote:
>
>>
>> On Dec 20, 2010, at 6:43 PM, William A. Rowe Jr. wrote:
>>
>>> On 12/16/2010 6:51 AM, Jim Jagielski wrote:
>>>> The Apache httpd 2.3.10-alpha test tarballs are available at:
>>>>
>>>> http://httpd.apache.org/dev/dist/
>>>>
>>>> Please vote on whether to release as 2.3.10-alpha.
>>>
>>> -1 on httpd-2.3.10-deps. pcre is missing, although apr, apr-util and
>>> even expat are there.
>>
>> Is that a regression?
>
> Maybe I'm just not seeing it, but I can't find pcre in the
> 2.3.6 nor the 2.3.8 deps either...
Irrelevant, you stated this is the final alpha, last chance to fix the
packaging to the alignment of beta.
But I'm reviewing the vote, I really don't know where we got to last
time this was discussed, it went in circles a few times, I don't see
the [Vote][Result]
When I posted the first message below, pgollucci and nikke concured,
pquerna and sctemme appeared to disagree with bundling it. Michael was
especially confused by the missing pcre (AIX).
In 2.3.8 non-vote discussion thread, guenter raised this again. pquerna
was extremely opposed to bundling it (2nd attach below), I agreed for the
converse reason that I expressed in the prior discussion. sctemme had some
ambiguous middle ground which seemed quite sane.
So the more that I think about it, there are vulnerable pcre's floating
around, which end up being httpd vulnerabilities, and by distributing the
freshest pcre 8.1 (whatever remains binary compatible) as we continue to
also ship apr makes sense. I'm in favor of making things easy on our
users, keeping httpd more secure, but not forcing any particular distro
of pcre on the users and let them default to their OS provided flavor.
We want -alpha, -beta adoption, provide a package called -deps, and don't
ship our manitory deps; that seems stupid.
For the reasons pquerna so elegantly expressed, it's also stupid to ship
apr-util and apr, when those vulnerabilities also roll down on httpd, and
users think they are blocked on a particular httpd (or httpd-deps) package.
So my vote on -deps becomes -0, and I will no longer vote on it at all
since the inclusion and discussion of -deps is intellectually inconsistent.
It won't be used anyways for packaging httpd binaries since I'd simply pick
up the current apr/apr-util/openssl/zlib/pcre anyways. I don't see a reason
to rely on a package of half of the -deps. It doesn't hurt or harm me, but
adoption is a concern.
I'm +1 on eliminating -deps altogether, but don't believe that such a
proposal has popular support.
--- Begin Message ---
Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [-1] Release httpd-2.3.4 as Alpha
for shipping the package httpd-2.3.4-deps; 1.4.0-dev is not released
and I strongly feel the httpd project isn't in the business of doing
so.
Look, PCRE is a mandatory component. APR is a mandatory component.
Let's please start applying some rhyme to our reasoning again.
--- End Message ---
--- Begin Message ---
On Tue, Aug 24, 2010 at 3:04 PM, Guenter Knauf <fua...@apache.org> wrote:
> Hi all,
> Am 24.08.2010 18:42, schrieb Jim Jagielski:
>>
>> The pre-release test tarballs for httpd-2.3.8 (alpha) are
>> available for download, test and fun:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> Will call for a release vote in a coupla days...
>
> I know that this topic was already up here, but nevertheless I think we
> should re-think about including PCRE again.
> Other than openssl or zlib PCRE is a mandatory dependency like APR/APU, and
> I see no benefit in dropping it from our dependencies deliveries other than
> making tarballs smaller, and that is nowadays certainly not an issue
> anymore.
> We want Apache to build form source on at many platforms as possible - sure
> the main target is Linux / Unix, but we have a couple of other platforms
> where PCRE is not installed by default, that are at least Win32, NetWare,
> most likely OS/2, and probably a couple of others too.
> I tried to build 2.3.7 already for NetWare and Win32, and while NetWare went
> fine only because I have an (self) adapted makefile (from previous times
> when we shipped PCRE), the Win32 stuff is horrible: there comes some
> suggestion up that I should build PCRE with CMake with xxx option; 1st I
> have to download CMake and depend on another build tool (ok, not that big
> issue), but whats even more worse is that the CMake build failed for me, and
> thats really bad - you cant just go and build httpd as you do on Linux, no!
> Your build process is always interupted, and probably as in my case finally
> broken at all.
> Hey, friends, we do much better with 2.2.x where we ship PCRE: we have our
> own makefile, and the build goes through in one go without need for other
> tools like CMake - just the compiler and probably a platform PDK are enough
> (and thats how it shoud be).
> Therefore I want to start a vote here again where we vote for including PCRE
> again with the dependencies - just as we (now) do with APR/APU;
> and everyone who votes against should give some good reasons what speaks
> against -- the fact that every Linux comes with PCRE is certainly no good
> reason - it only leads finally to the fact that we might end up with 50
> builds of httpd 2.after-2.x with different PCE versions which makes then
> nice bug hunting, and we cant even tell someone who faces a prob to 'use our
> shipping PCRE which is known to be good'.
>
> Here we go:
>
> [ ] YES - include recent PCRE again with dependencies (means we
> create a PCRE repo in svn, check in a recent version, and add
> platform-dependent makefiles which are fully integrated into
> main build process).
>
> [ ] NO - dont include PCRE (as currently) because of reason: ...
>
[X] NO:
There are 3-5 PCRE releases per year[1], and as a project our history
of staying up to date (including security and just bug fixes) was
generally pretty bad. Bundling our own PCRE is a security risk best
managed by operating system vendors who take care of backporting
patches to 4 year old versions, as an upstream I see very little value
in maintaining PCRE in tree, and plenty of risks.
It seems to enable porting on other platforms, we could make a shell
script that downloaded PCRE and any other dependencies like it
(OpenSSL?), but I don't believe this has a place in the main
distribution tarball.
Thanks,
Paul
[1] - http://www.pcre.org/news.txt
--- End Message ---
--- Begin Message ---
On Aug 24, 2010, at 3:04 PM, Guenter Knauf wrote:
Between your alternatives:
> [ ] YES - include recent PCRE again with dependencies (means we
> create a PCRE repo in svn, check in a recent version, and add
> platform-dependent makefiles which are fully integrated into
> main build process).
>
> [X] NO - dont include PCRE (as currently) because of reason: ...
I am OK with including the currently shipping PCRE in the -deps tarball,
together with the currently shipping APR and APU. So currently that would be
PCRE 8.10. I do not want us to maintain a fork. We used to maintain a fork:
we have very good reasons to not want to do that anymore.
If you have build improvements that make it easier to slide PCRE into srclib
and build it along with httpd, the right place for those is, IMHO, the
upstream.
I assume we could work with Philip to have him include our build bits. Pending
our proposal to him, a compromise I would entertain would be to include, in our
-deps tarball with the shipping PCRE, a patch file or zip file that has the
missing bits with a name like APPLY_TO_PCRE_ON_WIN32.ZIP (or APPLY_~1.ZIP,
modulo Netware) to allow builders on those platforms to set up their
environment. That file or those files would disappear as soon as the upstream
picks it up.
I regard the primary consumers of our source tarball to be packagers and
distributors, who can be expected to have extensive scaffolding in place.
Those who want to build their own should be served by the source and -deps,
just like Subversion does, to build a default configuration (./configure &&
make && sudo make install). Users who want to build non-default things should
be expected to pull in the dependencies themselves.
Note: by this reasoning, we should put libz in the dependencies since
mod_deflate is part of the default "most" complement. However, unless someone
(not me) comes up with the autofoo to build libz in absence of a viable
installed copy, we can let the mod_deflate autoconf soft fail like it does
today.
S.
--
Sander Temme
scte...@apache.org
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
--- End Message ---
