httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Evans <>
Subject Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Date Fri, 04 Dec 2009 11:56:43 GMT
On Fri, Dec 4, 2009 at 12:59 AM, Graham Leggett <> wrote:
> William A. Rowe Jr. wrote:
>> Ok, so they want to roll their own.  Sounds like a maintainer issue.  What
>> does this say for using our httpd rpm for an Ubuntu or other distribution
>> of linux?
> Ubuntu is Debian based, and uses the .deb packaging format, and startup
> scripts derived from the Debian layout. If someone was to donate debian
> packaging for httpd, I would expect one or two files to appear below
> build/deb, and that would be all that would be needed.
>> IMHO, if it is fundamentally incompatible with apachectl and non-redhat
>> distributions, let the the packagers tweak and take the zany customizations
>> out from under our problem set.
> Apachectl is archaic and largely broken for most people - it made sense
> ten years ago, it makes a lot less sense today.

Really? It works perfectly on all boxes I use it on. What precisely
has changed about reading a pid from a file, sending signals to a
process, or spawning a process with specific arguments that has made
apachectl 'archaic and largely broken', I am intrigued.

> The pattern followed by most modern unix based packaging is for an
> application to drop a snippet of config contained in a discrete file in
> a directory ending in ".d". So you have
> /etc/httpd/conf.d/<snippet>.conf, instead of a manual edit to
> /etc/httpd/conf/httpd.conf, and your httpd startup goes within an
> optional script called /etc/sysconfig/httpd instead of in a script file
> in a bin directory as apachectl wants. I understand Debian has different
> naming conventions, but otherwise the underlying principles are the same.

Did you mean to say 'most Linux' there? The OSes that I regularly use
do not display these redhatisms.

> In our case, we package up config files within standalone RPMs all of
> their own (suitably tagged and versioned), or we generate the config
> file using puppet. Editing a file in place is always painful and error
> prone, it is far less painful to provide a discrete file that can be
> dropped in and removed cleanly. Apachectl doesn't give us this - you
> need to edit apachectl directly to modify the command line parameters
> passed to httpd.
> As for the packagers tweaking and making zany customisations, that is
> exactly what they do now. For us it makes the their packaging unsuitable
> for our needs, simply because we tweak and make zany customisations for
> needs of our own. It is far less painful to take a vanilla RPM published
> by the ASF, and then tweak it for our needs, than it is to take a Fedora
> RPM, untweak all their customisations, and then retweak it with ours.

Ah so now the crux of your argument:

1) I use Fedora/RHEL
2) I want customized packages to install
3) Fedora/RHEL package their RPMs in such a way that it makes it
difficult for me to modify them.

It's much easier when you just say this up front.



View raw message