For reasons involving upgrading my office workstation to Fedora 18, I've had to deal with the stock Fedora Apache configuration setup for the first time in a long time. And oh boy, is it bad. It's a beautiful example of how not to do configuration files in a modern package manager world and is all the more shocking because I'm used to the Ubuntu Apache setup (which is the Debian Apache setup), which basically gets everything right.

Here is how Debian splits Apache configuration up:

• Apache modules put their configuration files in /etc/apache2/mods-available, but this doesn't enable them; there's a separate directory for that, /etc/apache2/mods-enabled. To enable a module you put appropriate symlinks in mods-enabled or, more likely, use a2enmod and a2dismod to do it for you.

• the configuration files for your websites are in /etc/apache2/sites-available; default is the default stock one (and default-ssl if applicable). However, once again, this doesn't enable them; that's /etc/apache2/sites-enabled, which has appropriate symlinks (managed by hand or with a2ensite and a2dissite as you prefer).

• configuration file snippets that don't otherwise fit go in /etc/apache2/conf.d. In a default configuration there is almost nothing in this directory that is active and most of it you don't want to touch.

• configuring the ports that Apache listens on has been split off into /etc/apache2/ports.conf (and this automatically handles SSL).

The remaining Apache configuration file is very short and consists mostly of comments; the Ubuntu 12.04 version has exactly 54 lines of configuration directives, most of them to set MPM parameters.

This is not perfectly modular, but in practice we can run a number of web servers, ranging from relatively simple to fairly complex, without needing to change any of the stock, package-provided files. The two most common changes (what your website setup actually is and controlling what Apache modules the server has enabled) both explicitly separate something simply being installed from it being enabled. Changing listening ports has been deliberately split off into its own file that has nothing else, so if you have to change it you still have a pristine main configuration file (that will keep being updated with package updates). You can remove or completely replace the default site just by removing and changing symlinks, while keeping the actual default around untouched for package updates (and to mine for ideas and so on).

Fedora, well, Fedora is not like this. It has no distinction between installed Apache modules and active Apache modules; if you have a module installed it drops a file in /etc/httpd/conf.modules.d and you can guess what happens next. It has no equivalent of even sites-enabled; your site is hardcoded in the main Apache configuration file along with a pile of other things (I'd call it 'your main site' except that Fedora doesn't even imagine that you might use virtual hosts). There is a directory for 'random configuration snippets', /etc/httpd/conf.d, but it's a complete mixed bag of actual general configuration directives and various packages adding Aliases and ScriptAliases to your site. It doesn't have any separation between installed and enabled either, and random Fedora packages feel free to drop bits in here (and in the process steal URLs out from underneath you).

All of this is catastrophically bad in the face of modern package management. In order to do anything with a Fedora Apache configuration you must change and delete files that are owned by various packages, leaving you to find and merge any future changes by hand (and you'd better also re-remove any files you removed when they're put back by package updates). This goes directly against years of experience of how to make things work well with package managers, and as Debian shows it's not as if Apache lacks the tools to create a genuinely modular and package manager friendly configuration. Nor is it as if Fedora is without experience at designing systems that work very well with modern package management.

(In practice the only thing you can really do with the Fedora Apache configuration is to burn it to the ground and start from scratch. Before I discovered the Debian way I had an approach for this, which I guess I get to repeat.)

There is a larger scale lesson for package management here that I encapsulated in a tweet, but explaining it properly is going to take another entry (this one is already long enough).