httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Date Fri, 04 Dec 2009 00:59:16 GMT
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.

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.

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.


View raw message