Software Correctness vs. Modernity
I've been pondering a problem inherent with this: https://aur.archlinux.org/packages.php?ID=16966
Arch's package management is a great thing. It's tidy, convenient, well-supported. Of all the Linux-based systems I've used, Arch's seems to be the most cogent and usable.
But it really isn't appropriate for daemontools.
This is the conundrum that something like daemontools faces. Whatever DJB's faults may be, his software is very well thought-out. He doesn't screw around with a lot of the inane common practices found among programmers. This is true partly because he's self-absorbed and vitriolic but that does mean that he isn't as likely to go with the crowd when they do silly things like use stdlib.h functions (a crusade that he happened to be quite right on as most of the legitimate complaints about C are actually complaints about stdlib.h).
The problem is that package management tends to revolve around the common programmer; who vomits out a solution quickly and spends forever after updating and maintaining that solution. This is a habit that we tend to inherit from the commoditized software philosophy (where the bits themselves are the thing to be sold and thus, generating new bits to sell is encouraged). While it is true that many solutions do warrant frequent revisiting, it is occasionally possible to solve a problem once and forever; mathematically solved.
This is the sort of thing DJB goes for. Consequently, he never markets his software, he only updates it when there is a fundamental flaw in the design, and adding features to his software requires a mandate from the Almighty.
It's uncharacteristic for software to be as easy to install from source the way DJB's software tends to be. qmail is a mighty pain to configure but daemontools, ucspi-tcp, and tinydns are all quite effortless for me to get fully operational and I'm unixtarded. Because installing from source is so easy, anybody with experience with these tools just doesn't see the point of packaging daemontools; the effort of installing with yaourt [https://aur.archlinux.org/packages.php?ID=5863] is not certain to be less than just compiling them yourself.
But this introduces a challenge. People don't want to break the stride their OS has set for them and so they tend to never even become aware of packages not found in their system's standard package repository. But if nobody actually uses the perma-solution you've made, how solved is the problem?
Package maintainers want things to be as automagical as possible -- which is fine but it comes with the implicit risk of introducing bugs in the automagical mechanisms. Such bugs reflect poorly on software that may have worked just dandy if it were installed from source. It becomes difficult for the user to understand why they should care about the packaged software in question.
DJB's attitude towards his own software is especially a problem for the Arch community which stresses modernity to the point where if you go more than a year without patching your software, you've "abandoned" it and they won't support it. While this attitude makes perfect sense for software systems where the authors are still groping to understand the problem (much less the solution they're trying to provide for it), if you are lucky enough to have permanently solved a problem, you'll get stuffed into the arbitrary obsolescence box.
So I'm torn. On the one hand, I'd love to see more people using something as correct as daemontools but on the other, I really don't see the point in packaging it. It's the sort of dichotomy that drives artists to kill themselves.