Tuesday, August 27, 2013

Installer Tips for Open Source Developers

So, I've recently had to install a lot of software from source. I used to do this a lot — back in the days when I was a Linux hobbyist and had nothing better to do — but in recent years, I have tended to just live with whatever versions of software libraries come with whatever Linux distro I happen to be using on a particular machine, usually the latest Ubuntu LTS (although I've used Slackware, Red Hat, SuSE, Mandriva, Yellow Dog, and CentOS in addition to Irix, Solaris, and FreeBSD).

One thing that hasn't changed one iota in (almost) twenty years is the utter cluelessness of niche developers when it comes to packaging their software, and it's driving me nuts. Just because your software isn't totally mainstream doesn't mean you can subject your (potential) users to an installation nightmare of manually editing Makefiles and making decisions about minutiae of configuration and installation.

The rules are very, very, simple indeed. Everyone who's ever installed anything from source knows the rules, so why the hell don't niche developers?

Here it is. The standard way of installing from source is

After I download a (well-behaved tarball), I expect to be able to do this:

    $ tar xzf foo-1.2.3.tar.gz
    $ cd foo-1.2.3
    $ ./configure
    $ make
    $ make test|check
    $ sudo make install

There are a small number of variations, of course, you can use 7zip or bzip2 instead of gzip, and so on. At a push, you can inflict CMake or SCons on me, but, frankly, I don't care how much of a pain in the hole the Autotools are (and, as a developer, I hate them), ideally you should use them because that's what your users expect, and they don't really care if it takes you a day of frustration to figure out. If that's significant in the context of your overall software development, it's probably not worth installing your software in the first place.

If you insist on inflicting your egotistical notions of how installation from source should work, the one thing you absolutely cannot do is ignore now well-established conventions about where stuff goes: absent any explicit instruction from me, you install your shit in the appropriate directories in /usr/local and nowhere else. I don't care that it's easier for you to just copy great gobs of shit into /opt/IAmSoImportant and leave all the painful configuration to me, and for the love of all that is good and right, if you install anything directly in /usr, interfering with the packaging system of my distro, I will hunt you down like a rabid dog and hammer a mechanical pencil into your eye with your detached and still-bleeding leg. I know it's hard to decide whether you should put your headers directly in /usr/local/include or in a subdirectory thereof, or your libraries in /usr/local/lib or in a subdirectory thereof, and it's often subtly debatable how “platform independent” that file really is, so whether it should go in /usr/local/share/foo or somewhere else is, in the end, a judgement call. I know. I sympathise. I really do. But if you can't decide, and you wrote the damn thing, how the hell do you expect me to?

In short, if you want your software to ever have the slightest chance of “catching on” and becoming popular, you can't just do the fun stuff, you have to suck it up, make a decision or two, and do the mundane and tedious stuff that makes installation easy for your users and packaging easy for distributions.

End of rant :o)

No comments:

Post a Comment