Arch Linux

pgoetz

Member

From: Austin, Texas

Registered: 2014-02-21

Posts: 355

[SOLVED] Some minor issues with Apache packaging

I'm not sure where to discuss issues relating to how Core/Extra/Community packages are packaged, so I'm posting some thoughts about the Apache package here.  I tried emailing the current package maintainers (one of whom doesn't appear in PKGBUILD), but didn't get a response.

My comment is that this symlink in PKGBUILD

  ln -fs /usr/lib/httpd/modules "${pkgdir}/etc/httpd/modules"

isn't terribly useful.  Larding /etc/httpd/httpd.conf with LoadModule commands turns into a huge mess once you start adding module configuration information as well.  Even more so in the normal case where you're using external modules (e.g. PHP) and even more so when you have sandboxed WSGI environments for particular web applications.

I'm used to the debian/Ubuntu scheme where LoadModule commands are kept as individual files which are linked to a "live" directory that's included in httpd.conf, but took the opportunity of switching to Arch to improve on this by also including the module configuration directives in the same file with the LoadModule command, so each module has all it's related information self-contained in a single file.  This massively simplifies httpd.conf and reduces the chance for error.

This is far removed from upstream, though.  Sticking to the philosophy of "stay as close to upstream as possible" I would suggest removing the symlink referenced above as it appears to not be from upstream, and encourages poor httpd configuration practices.

The same comments hold for how virtual hosts are handled:  the scheme set up by the Apache PKGBUILD is unusable for anyone that has more than one or two virtual hosts.  Again, I generally like the way debian solved this problem (everything is a virtual host, each virtual host is configured in it's own file, with the active ones linked to a "live" directory that's included in httpd.conf), but this is also far removed from upstream.  Having the /etc/httpd/conf/extra conf files available as examples is probably the best that can be accomplished here without dictating non-upstream configuration to apache admins.  If you're an apache admin who is managing, say 4+ virtual hosts on the same machine and are not doing something like the debian approach, I strongly encourage you to take a look at this way of doing things.  I've done it both ways and can vouch for the reduced headaches and simplicity of the modular approach.

Comments?  It's generally a pain in the butt that I have to through and read the online descriptions of every module in order to determine what is needed to enable a particular functionality.  At this point a module dependency tree (or better, setting it up so that modules can load their own dependencies and simplifying the list of modules that are user selectable) is long overdue (but that's an upstream apache issue).

I'm good with the keep things as close to upstream as possible and then build a separate configuration package if needed approach, but then the package maintainers need to follow through on the former to avoid adding complexity to the configuration package.  Once this stuff gets into the main application package, it's hard to take it out, as people have built configurations which depend on it.

Last edited by pgoetz (2014-04-15 08:25:24)

loafer

Member

From: the pub

Registered: 2009-04-14

Posts: 1,772

Re: [SOLVED] Some minor issues with Apache packaging

I think submitting a request to the bug tracker would be the standard way to address this.

---

All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.

pgoetz

Member

From: Austin, Texas

Registered: 2014-02-21

Posts: 355

Re: [SOLVED] Some minor issues with Apache packaging

I think submitting a request to the bug tracker would be the standard way to address this.

Thanks.  I'm busy rethinking all  these comments, and will file something on bug tracker when it's clear in my mind what makes the most sense.  Apache configuration has always been a mess, and it's bothered me for years.  Switching to Arch has been a good opportunity to put some thought into how to make it more sensible.