On Fri, Dec 4, 2009 at 12:59 AM, Graham Leggett <[email protected]> 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. Cheers Tom
