For a while I’ve been maintaining my own WordPress packages. I use quite a few plugins that weren’t included in Debian, some of them have unclear licenses so they can’t go in Debian while the rest would have to go in Volatile at best because they update regularly and often have little or no information in the changelog to describe the reason for the update – so we have to assume there is a potential security issue and update it reasonably quickly. As I’m maintaining plugin packages it seems most reasonable to keep maintaining my own packages of WordPress itself which I started doing some time ago then the version in Debian became outdated.
Now WordPress isn’t a convenient package to maintain, the design of it is that a user will upload it to their web space via FTP or whatever, it’s not designed to be managed by a packaging system with the option of rolling back upgrades that don’t work, tracking dependencies, etc. One example of this is the fact that it comes with a couple of plugins included in the package, of which Akismet is widely used. The Akismet package is periodically updated asynchronously from the updates to the WordPress package with the apparent expectation that you can just FTP the files. Of course I have to build a new WordPress package whenever Akismet is changed.
Now there is a new default theme for WordPress called TwentyTen [1]. This theme ships with WordPress and again has updates asynchronously. Just over a week ago my blog prompting me for an update to the theme even though I hadn’t consciously installed it – I have to update because I don’t know whether one of the other users on the same system has chosen it and because having a message about an update being required is annoying.
The Themes update page has no option for visiting the web site for the theme and only offered to send it to my server via FTP or SFTP, of course I’m not going to give WordPress access to change it’s own PHP files (and thus allow a trojan to be installed). So I had to do some Google searching to find the download page for TewntyTen – which happens to not be in the first few results from a Google search (even though those pages look like they should have a link to it and thus waste the time of anyone who just wants to download it).
After downloading the theme I had to build a new WordPress package containing it – I could have split it out into a separate package and have the WordPress package depend on it, but I’ve got enough little WordPress packages already. It doesn’t seem worth-while to put too much effort into my private repository of WordPress packages that possibly aren’t used by anyone other than me.
Plugins aren’t as bad, the list of plugins gives you a link to the main web page for each plugin which allows you to download it.
I wonder what portion of the WordPress user-base install via FTP to a server that they don’t understand and what portion of them use servers that are maintained properly with a packaging system, my guess is that with the possible exception of WordPress.com most bloggers are running on packaged code. It seems to me that optimising for Debian and CentOS is the smart thing to do for anyone who is developing a web service nowadays. That includes files managed by the packaging system, an option to downgrade (as well as upgrade) the database format (which changes with almost every release), and an option for upgrading the database from the command-line (so it can be done once for dozens or hundreds of users).
deb http://www.coker.com.au lenny wordpress
I have a repository of WordPress packages that anyone can use with the above APT sources.list line. There is no reason why they shouldn’t work with Testing or Unstable (the packaging process mostly involves copying PHP files to the correct locations) but I only test them on Lenny.