Mailing List Archive: Apache: Dev

documenting -deps

Index | Next | Previous | View Threaded

covener at gmail

Jan 17, 2012, 12:07 PM

Post #1 of 17 (654 views)
Permalink

documenting -deps

* Are we committed to providing the -deps for 2.4's lifetime, or would
we doc it with some weasel language?

* Does anyone care if we're not committed to it and just change the
doc when we change our mind and stop providing a deps tarball?

wrowe at rowe-clan

Jan 17, 2012, 12:15 PM

Post #2 of 17 (639 views)
Permalink

Re: documenting -deps [In reply to]

On 1/17/2012 2:07 PM, Eric Covener wrote:
> * Are we committed to providing the -deps for 2.4's lifetime, or would
> we doc it with some weasel language?

I'm +1 for dropping -deps, but you knew that ;-)

> * Does anyone care if we're not committed to it and just change the
> doc when we change our mind and stop providing a deps tarball?

No... we need some doc to help users. Looking at the users@ list has been
instructive. I really think we need 2.4.0-beta to iron out how hard it is
now for users to adopt this package, and what we have to document in order
to remedy that complexity.

minfrin at sharp

Jan 17, 2012, 12:31 PM

Post #3 of 17 (634 views)
Permalink

Re: documenting -deps [In reply to]

On 17 Jan 2012, at 10:07 PM, Eric Covener wrote:

> * Are we committed to providing the -deps for 2.4's lifetime, or would
> we doc it with some weasel language?
>
> * Does anyone care if we're not committed to it and just change the
> doc when we change our mind and stop providing a deps tarball?

The simplest fix for this issue is to modify the "file not found" error message to say something sensible about requiring the -deps package.

At the end of the day, the most likely reason someone is trying to add --with-included-apr is because they did this in the past, and these people aren't going to have looked in any documentation, and so won't find any explanation for what to do.

Regards,
Graham
--

Attachments:

smime.p7s (4.26 KB)

gls at gknw

Jan 17, 2012, 12:32 PM

Post #4 of 17 (636 views)
Permalink

Re: documenting -deps [In reply to]

On 1/17/2012 12:15 PM, William A. Rowe Jr. wrote:
> On 1/17/2012 2:07 PM, Eric Covener wrote:
>> * Are we committed to providing the -deps for 2.4's lifetime, or would
>> we doc it with some weasel language?
> I'm +1 for dropping -deps, but you knew that ;-)
>
>> * Does anyone care if we're not committed to it and just change the
>> doc when we change our mind and stop providing a deps tarball?
> No... we need some doc to help users. Looking at the users@ list has been
> instructive. I really think we need 2.4.0-beta to iron out how hard it is
> now for users to adopt this package, and what we have to document in order
> to remedy that complexity

2 cents

Why not just do it how it has always been done, that is to include the
latest release of APR/APU(/APR-I on Win) for the httpd release? It seems
to me if I recall this correctly, that the reason there was a separate
-deps package was because APR 1.4 was not released, therefore could not
be bundled yet was required for 2.3.x at the time of release.

I know PCRE was axed and the reason is sound. APR however, is part of
ASF and maintained by most of you anyway.

The preferred needed APR & APU are all in a released state, what's the
problem bundling again?

Regards,

Gregg

minfrin at sharp

Jan 17, 2012, 12:42 PM

Post #5 of 17 (632 views)
Permalink

Re: documenting -deps [In reply to]

On 17 Jan 2012, at 10:32 PM, Gregg L. Smith wrote:

> Why not just do it how it has always been done, that is to include the latest release of APR/APU(/APR-I on Win) for the httpd release? It seems to me if I recall this correctly, that the reason there was a separate -deps package was because APR 1.4 was not released, therefore could not be bundled yet was required for 2.3.x at the time of release.
>
> I know PCRE was axed and the reason is sound. APR however, is part of ASF and maintained by most of you anyway.
>
> The preferred needed APR & APU are all in a released state, what's the problem bundling again?

Both APR and APR-Util are standalone packages, and are deployed in their own right on systems, just like other dependencies like OpenSSL or db4, and this has been so for many years.

Bundling them causes confusion and clashes with these system installed packages. Those that need included APR/APR-Util should be the exception, not the rule.

Regards,
Graham
--

Attachments:

smime.p7s (4.26 KB)

isoma at jellybaby

Jan 17, 2012, 12:45 PM

Post #6 of 17 (633 views)
Permalink

Re: documenting -deps [In reply to]

On 17 Jan 2012, at 20:31, Graham Leggett wrote:

> The simplest fix for this issue is to modify the "file not found" error message to say something sensible about requiring the -deps package.
>
> At the end of the day, the most likely reason someone is trying to add --with-included-apr is because they did this in the past, and these people aren't going to have looked in any documentation, and so won't find any explanation for what to do.

This is what I would have expected. But my autoconf is not up to making a patch.

How about adding a hyperlink to a page that explains the change and ways to deal with it?

--
Tim Bannister � isoma [at] jellybaby

Attachments:

smime.p7s (4.29 KB)

wrowe at rowe-clan

Jan 17, 2012, 12:55 PM

Post #7 of 17 (635 views)
Permalink

Re: documenting -deps [In reply to]

On 1/17/2012 2:32 PM, Gregg L. Smith wrote:
>
> The preferred needed APR & APU are all in a released state, what's the problem bundling
> again?

Because they don't stay released.

APR and APU have updates and security patches which are out of step
with httpd. As anyone who's been involved in a large, collective
work knows, having one "project" gated on releases from a host of
projects is bad mojo for the collective one.

Here, we ship source code. So delivering httpd and letting the
user, at any point in time, pick up the freshest apr and apr-util
is optimal.

And, I can re-roll a windows binary, for example, with a newly
released apr. Under our one-bundle approach, that really is not
possible, because httpd hasn't shipped an httpd + apr.new.

Bill

wrowe at rowe-clan

Jan 17, 2012, 12:56 PM

Post #8 of 17 (635 views)
Permalink

Re: documenting -deps [In reply to]

On 1/17/2012 2:31 PM, Graham Leggett wrote:
> On 17 Jan 2012, at 10:07 PM, Eric Covener wrote:
>
>> * Are we committed to providing the -deps for 2.4's lifetime, or would
>> we doc it with some weasel language?
>>
>> * Does anyone care if we're not committed to it and just change the
>> doc when we change our mind and stop providing a deps tarball?
>
> The simplest fix for this issue is to modify the "file not found" error message to say something sensible about requiring the -deps package.

make -F makefile.win emits this very sort of message, pointing the user
to obtain the right package.

minfrin at sharp

Jan 17, 2012, 1:14 PM

Post #9 of 17 (634 views)
Permalink

Re: documenting -deps [In reply to]

On 17 Jan 2012, at 10:56 PM, William A. Rowe Jr. wrote:

>> The simplest fix for this issue is to modify the "file not found" error message to say something sensible about requiring the -deps package.
>
> make -F makefile.win emits this very sort of message, pointing the user
> to obtain the right package.

And now ./configure does too in r1232575:

Little-Net:httpd-trunk minfrin$ ./configure --with-included-apr
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking build system type... x86_64-apple-darwin10.8.0
checking host system type... x86_64-apple-darwin10.8.0
checking target system type... x86_64-apple-darwin10.8.0

Configuring Apache Portable Runtime library ...

configure: error: Bundled APR requested but not found at srclib/apr. Download and unpack the corresponding httpd-2.5.0-deps package over this one.

Regards,
Graham
--

Attachments:

smime.p7s (4.26 KB)

jim at jaguNET

Jan 18, 2012, 4:22 AM

Post #10 of 17 (621 views)
Permalink

Re: documenting -deps [In reply to]

On Jan 17, 2012, at 3:42 PM, Graham Leggett wrote:

> On 17 Jan 2012, at 10:32 PM, Gregg L. Smith wrote:
>
>> Why not just do it how it has always been done, that is to include the latest release of APR/APU(/APR-I on Win) for the httpd release? It seems to me if I recall this correctly, that the reason there was a separate -deps package was because APR 1.4 was not released, therefore could not be bundled yet was required for 2.3.x at the time of release.
>>
>> I know PCRE was axed and the reason is sound. APR however, is part of ASF and maintained by most of you anyway.
>>
>> The preferred needed APR & APU are all in a released state, what's the problem bundling again?
>
> Both APR and APR-Util are standalone packages, and are deployed in their own right on systems, just like other dependencies like OpenSSL or db4, and this has been so for many years.
>
> Bundling them causes confusion and clashes with these system installed packages. Those that need included APR/APR-Util should be the exception, not the rule.
>

For the beta, it was deemed Good to bundle the required versions of
apr/apu; for the GAs, not so much.

I'm +1 for not bundling them.

wrowe at rowe-clan

Jan 31, 2012, 9:04 AM

Post #11 of 17 (593 views)
Permalink

Re: documenting -deps [In reply to]

On 1/18/2012 6:22 AM, Jim Jagielski wrote:
>
> On Jan 17, 2012, at 3:42 PM, Graham Leggett wrote:
>
>> On 17 Jan 2012, at 10:32 PM, Gregg L. Smith wrote:
>>
>>> Why not just do it how it has always been done, that is to include the latest release of APR/APU(/APR-I on Win) for the httpd release? It seems to me if I recall this correctly, that the reason there was a separate -deps package was because APR 1.4 was not released, therefore could not be bundled yet was required for 2.3.x at the time of release.
>>>
>>> I know PCRE was axed and the reason is sound. APR however, is part of ASF and maintained by most of you anyway.
>>>
>>> The preferred needed APR & APU are all in a released state, what's the problem bundling again?
>>
>> Both APR and APR-Util are standalone packages, and are deployed in their own right on systems, just like other dependencies like OpenSSL or db4, and this has been so for many years.
>>
>> Bundling them causes confusion and clashes with these system installed packages. Those that need included APR/APR-Util should be the exception, not the rule.
>>
>
> For the beta, it was deemed Good to bundle the required versions of
> apr/apu; for the GAs, not so much.
>
> I'm +1 for not bundling them.

Was this thread abandoned?

I'm also +1 for not bundling them.

But with -deps, or without, are the docs@ up to date with respect to 2.4's
prerequisites on unix? I know the Windows docs to be out of date and will
edit those build docs by the end of the week.

jim at jaguNET

Jan 31, 2012, 9:30 AM

Post #12 of 17 (597 views)
Permalink

Re: documenting -deps [In reply to]

Just to be clear, the current thinking is that we do not bundle
apr/apu at all with 2.4.x... either as a sep tarball (the -deps),
nor simply slapped in there (ala 2.2.x)...

I wonder if the issue is that we call that tarball httpd...-deps. I
wonder if people would think differently if we named it httpd...-aprlibs
or something like that, which makes it clear that we're providing apr/apu
simply as a Nice Thing for our end users, but not as a *dependency*,
which carries a different connotation ...

wrowe at rowe-clan

Jan 31, 2012, 9:49 AM

Post #13 of 17 (597 views)
Permalink

Re: documenting -deps [In reply to]

On 1/31/2012 11:30 AM, Jim Jagielski wrote:
> Just to be clear, the current thinking is that we do not bundle
> apr/apu at all with 2.4.x... either as a sep tarball (the -deps),
> nor simply slapped in there (ala 2.2.x)...
>
> I wonder if the issue is that we call that tarball httpd...-deps. I
> wonder if people would think differently if we named it httpd...-aprlibs
> or something like that, which makes it clear that we're providing apr/apu
> simply as a Nice Thing for our end users, but not as a *dependency*,
> which carries a different connotation ...

Don't they get the same thing by looking in ../apr/ from the very same
distribution mirrors? Seems like storage waste to me.

Don't the independently need to obtain pcre to even get httpd to build?
How is pcre different than apr? Have we documented that prerequisite?

And to build apr+util, they probably want to have obtained and installed
expat, openssl, and if part of their clib, iconv.

Best yet, they probably won't be

So unless every RM "-convenience" package

wrowe at rowe-clan

Jan 31, 2012, 9:50 AM

Post #14 of 17 (593 views)
Permalink

Re: documenting -deps [In reply to]

On 1/31/2012 11:30 AM, Jim Jagielski wrote:
> Just to be clear, the current thinking is that we do not bundle
> apr/apu at all with 2.4.x... either as a sep tarball (the -deps),
> nor simply slapped in there (ala 2.2.x)...
>
> I wonder if the issue is that we call that tarball httpd...-deps. I
> wonder if people would think differently if we named it httpd...-aprlibs
> or something like that, which makes it clear that we're providing apr/apu
> simply as a Nice Thing for our end users, but not as a *dependency*,
> which carries a different connotation ...

No. It is a dependency. It is not convenient, unless the HTTP Server
RM's are all committed to repackaging all of the -deps every time the
APR project introduces a security fix or significant bug fix.

Providing the wrong packages for any given point in time is not
a convenience, it is a disservice.

wrowe at rowe-clan

Jan 31, 2012, 9:51 AM

Post #15 of 17 (597 views)
Permalink

Re: documenting -deps [In reply to]

On 1/31/2012 11:49 AM, William A. Rowe Jr. wrote:
>
> Best yet, they probably won't be
>
> So unless every RM "-convenience" package

Scratch that. Stupid touchpad.

jim at jaguNET

Jan 31, 2012, 11:40 AM

Post #16 of 17 (597 views)
Permalink

Re: documenting -deps [In reply to]

On Jan 31, 2012, at 12:50 PM, William A. Rowe Jr. wrote:

> On 1/31/2012 11:30 AM, Jim Jagielski wrote:
>> Just to be clear, the current thinking is that we do not bundle
>> apr/apu at all with 2.4.x... either as a sep tarball (the -deps),
>> nor simply slapped in there (ala 2.2.x)...
>>
>> I wonder if the issue is that we call that tarball httpd...-deps. I
>> wonder if people would think differently if we named it httpd...-aprlibs
>> or something like that, which makes it clear that we're providing apr/apu
>> simply as a Nice Thing for our end users, but not as a *dependency*,
>> which carries a different connotation ...
>
> No. It is a dependency. It is not convenient, unless the HTTP Server
> RM's are all committed to repackaging all of the -deps every time the
> APR project introduces a security fix or significant bug fix.
>
> Providing the wrong packages for any given point in time is not
> a convenience, it is a disservice.
>

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.

noel.butler at ausics

Jan 31, 2012, 4:01 PM

Post #17 of 17 (595 views)
Permalink

Re: documenting -deps [In reply to]

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,
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
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 -
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
<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 (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.

Attachments:

signature.asc (0.48 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads