You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2011/11/29 01:37:20 UTC
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
On Mon, Nov 28, 2011 at 7:24 PM, <mi...@apache.org> wrote:
> Author: minfrin
> Date: Tue Nov 29 00:24:35 2011
> New Revision: 1207721
>
> URL: http://svn.apache.org/viewvc?rev=1207721&view=rev
> Log:
> RPM: The default httpd mpm is now worker instead of prefork.
FWIW
* a normal build defaults to event
* a multi-MPM build of 2.4 "should" build the MPMs as DSOs
Is the RPM design supposed to be aligned with anything else outside of
httpd 2.4? Is there some external tooling that expects MPMs to be
built as with 2.2? Also, I presume that the build flavor shouldn't
change within 2.4.x?
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Nov 28, 2011 at 7:52 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 29 Nov 2011, at 02:37, Jeff Trawick wrote:
>
>> FWIW
>>
>> * a normal build defaults to event
>> * a multi-MPM build of 2.4 "should" build the MPMs as DSOs
>
> +1.
>
> This is what I'm trying to nail down - to get the packaging to work against the ideal installation of httpd.
>
> What I am also keen to do is identify modules that bind to external libraries, and spin them out into dedicated RPMs like we always did with mod_ssl, the idea being that an installation of the basic server shouldn't bring in any onerous dependencies on a system.
cool/thanks! (butting out now)
>
>> Is the RPM design supposed to be aligned with anything else outside of
>> httpd 2.4? Is there some external tooling that expects MPMs to be
>> built as with 2.2? Also, I presume that the build flavor shouldn't
>> change within 2.4.x?
>
> Originally we adopted the Redhat RPM spec file to make it easy for people to drop the ASF provided RPM onto a system and have it work reasonably closely to the original system, but our packaging has moved ahead of Redhat's at this point (to my knowledge, anyway).
>
> I hope that other vendors will pick up our packaging as the "canonical" way, and improve the way httpd is deployed out there.
>
> Regards,
> Graham
> --
>
>
--
Born in Roswell... married an alien...
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by Rainer Jung <ra...@kippdata.de>.
On 04.12.2011 14:15, Rainer Jung wrote:
> On 29.11.2011 13:12, Graham Leggett wrote:
>> On 29 Nov 2011, at 11:55, Igor Galić wrote:
>>
>>> OpenSSL (and cascading deps to it)
>>> mod_ssl
>>> mod_session
>>> mod_session_crypto
>>
>> Neither mod_session nor mod_session_crypto have any hard coded links
>> to openssl (or any other library), it's all abstracted away. mod_ssl
>> has always been packaged separately.
>
> Probably Igor meant to say that mod_ssl depends on mod_session for its
> own SSL session store. So there's a dependency between modules.
Sorry, confused myself, that's the so_cache module needed for SSL sessions.
Regards,
Rainer
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by Rainer Jung <ra...@kippdata.de>.
On 29.11.2011 13:12, Graham Leggett wrote:
> On 29 Nov 2011, at 11:55, Igor Galić wrote:
>
>> OpenSSL (and cascading deps to it)
>> mod_ssl
>> mod_session
>> mod_session_crypto
>
> Neither mod_session nor mod_session_crypto have any hard coded links to openssl (or any other library), it's all abstracted away. mod_ssl has always been packaged separately.
Probably Igor meant to say that mod_ssl depends on mod_session for its
own SSL session store. So there's a dependency between modules.
Regards,
Rainer
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/29/2011 12:23 PM, William A. Rowe Jr. wrote:
> On 11/29/2011 6:12 AM, Graham Leggett wrote:
>> On 29 Nov 2011, at 11:55, Igor Galić wrote:
>>
>>> And, our all time favourite: LDAP.
>>
>> This definitely needs separating out until it's abstraction is fixed.
>
> Not possible due to your veto; non-optional ldap dependency of apr-util,
> upon which httpd depends.
Ah, right... possible but convoluted...
httpd-ldap -> apr-ldap-1
| |
V V
httpd -> apr_util-1 -> apr
Should really just veto such a nonsense change, since httpd had an actual
solution in hand, before it was obstructed.
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/29/2011 6:12 AM, Graham Leggett wrote:
> On 29 Nov 2011, at 11:55, Igor Galić wrote:
>
>> And, our all time favourite: LDAP.
>
> This definitely needs separating out until it's abstraction is fixed.
Not possible due to your veto; non-optional ldap dependency of apr-util,
upon which httpd depends.
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 29 Nov 2011, at 11:55, Igor Galić wrote:
> OpenSSL (and cascading deps to it)
> mod_ssl
> mod_session
> mod_session_crypto
Neither mod_session nor mod_session_crypto have any hard coded links to openssl (or any other library), it's all abstracted away. mod_ssl has always been packaged separately.
> liblua:
> mod_lua
This one needs to be packaged separately.
> libxml2:
> mod_proxy_html
> mod_xml2enc
These modules consume libxml2 directly, so are in the same boat as LDAP.
> $DB:
> Everything_ending_in_dbd
Like mod_session, everything related to dbd is abstracted away properly, and doesn't absorb any stray dependencies.
> And, our all time favourite: LDAP.
This definitely needs separating out until it's abstraction is fixed.
> DBM: mod_authn_dbm and mod_authz_dbm
Again, both abstracted away properly.
> But there's also the new: mod_nw_ssl, which only applies to NetWare.
The RPM is only interested in modules that apply to unix platforms at this point.
Regards,
Graham
--
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 29 November 2011, Igor Galić wrote:
> > I hope that other vendors will pick up our packaging as the
> > "canonical" way, and improve the way httpd is deployed out there.
>
> +1
>
> sf - how are you planning to do this, btw ;)
I think we are going to drop the separate MPM packages and build all
MPMs shared. I don't think we are going to move packages into separate
modules, though. The dependencies are either very small (lua) or
installed on most systems anyway (openssl, libxml).
Apart from that, I haven't thought much about it, yet. I guess the
Debian packages won't change very much.
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On 29 Nov 2011, at 02:37, Jeff Trawick wrote:
>
> > FWIW
> >
> > * a normal build defaults to event
> > * a multi-MPM build of 2.4 "should" build the MPMs as DSOs
>
> +1.
>
> This is what I'm trying to nail down - to get the packaging to work
> against the ideal installation of httpd.
>
> What I am also keen to do is identify modules that bind to external
> libraries, and spin them out into dedicated RPMs like we always did
> with mod_ssl, the idea being that an installation of the basic
> server shouldn't bring in any onerous dependencies on a system.
OpenSSL (and cascading deps to it)
mod_ssl
mod_session
mod_session_crypto
liblua:
mod_lua
libxml2:
mod_proxy_html
mod_xml2enc
$DB:
Everything_ending_in_dbd
And, our all time favourite: LDAP.
DBM: mod_authn_dbm and mod_authz_dbm
But there's also the new: mod_nw_ssl, which only applies to NetWare.
> > Is the RPM design supposed to be aligned with anything else outside
> > of
> > httpd 2.4? Is there some external tooling that expects MPMs to be
> > built as with 2.2? Also, I presume that the build flavor shouldn't
> > change within 2.4.x?
>
> Originally we adopted the Redhat RPM spec file to make it easy for
> people to drop the ASF provided RPM onto a system and have it work
> reasonably closely to the original system, but our packaging has
> moved ahead of Redhat's at this point (to my knowledge, anyway).
>
> I hope that other vendors will pick up our packaging as the
> "canonical" way, and improve the way httpd is deployed out there.
+1
sf - how are you planning to do this, btw ;)
> Regards,
> Graham
> --
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: svn commit: r1207721 - in /httpd/httpd/branches/2.4.x: ./ build/rpm/httpd.spec.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 29 Nov 2011, at 02:37, Jeff Trawick wrote:
> FWIW
>
> * a normal build defaults to event
> * a multi-MPM build of 2.4 "should" build the MPMs as DSOs
+1.
This is what I'm trying to nail down - to get the packaging to work against the ideal installation of httpd.
What I am also keen to do is identify modules that bind to external libraries, and spin them out into dedicated RPMs like we always did with mod_ssl, the idea being that an installation of the basic server shouldn't bring in any onerous dependencies on a system.
> Is the RPM design supposed to be aligned with anything else outside of
> httpd 2.4? Is there some external tooling that expects MPMs to be
> built as with 2.2? Also, I presume that the build flavor shouldn't
> change within 2.4.x?
Originally we adopted the Redhat RPM spec file to make it easy for people to drop the ASF provided RPM onto a system and have it work reasonably closely to the original system, but our packaging has moved ahead of Redhat's at this point (to my knowledge, anyway).
I hope that other vendors will pick up our packaging as the "canonical" way, and improve the way httpd is deployed out there.
Regards,
Graham
--