As many of you know, I maintain the #lobsters IRC channel bot, Mock Turtle. That bot notifies IRC of story submissions to lobste.rs. It works by using the mailing list mode, and so runs an email server and converts incoming messages to IRC notifications.
I’m pleased to announce that, on the release of notqmail-1.07, the bot is using notqmail to receive these messages.
This begs a question I haven’t seen answered elsewhere though. What would be the reasons for a sysadmin to invest time and effort into (not)qmail? Other implementations (such as Postfix) seem to meet an equal standard of stability, while already providing the features you want to implement in notqmail.
For the moment, we’re targeting sysadmins who already run (net)qmail. Much later, when we begin to approach feature parity with Postfix, notqmail might start being an interesting alternative. We hope that time will come. If you can’t figure out why you’d run it right now, you’re probably right :-)
We see new software popping out (on Github) and fading (on SourceForge) all of the time, but former software updated by different maintainers, not so often.
I bet it gives a different feeling this way, a sense of continuity.
This was the script I was packaging netqmail with.
#!/bin/sh -ex
mkdir -p /var/qmail
mkdir -p /etc/qmail
mkdir -p "$PREFIX/bin"
rm -rf /var/qmail/control
ln -sf /etc/qmail /var/qmail/control
ln -sf "$PREFIX/bin" /var/qmail
user() {
if [ "$(readlink -f "$(which adduser)" | sed 's;.*/;;')" = "busybox" ]; then
adduser -D -s "$1" -G "$2" -h "3" "$4"
else
useradd -s "$1" -g "$2" -d "$3" "$4"
fi
}
group() {
if [ "$(readlink -f "$(which addgroup)" | sed 's;.*/;;')" = "busybox" ]; then
addgroup "$1"
else
groupadd "$1"
fi
}
! group nofiles
! user "$(which true)" nofiles /var/qmail/alias alias
! user "$(which true)" nofiles /var/qmail qmaild
! user "$(which true)" nofiles /var/qmail qmaill
! user "$(which true)" nofiles /var/qmail qmailp
! group qmail
! user "$(which true)" qmail /var/qmail qmailq
! user "$(which true)" qmail /var/qmail qmailr
! user "$(which true)" qmail /var/qmail qmails
! user "$(which true)" qmail /var/qmail alias
touch nroff
chmod +x nroff
export PATH="$PATH:$PWD"
make setup
rm -rf "$PREFIX/share/man"
mkdir -p "$PREFIX/share"
mv /var/qmail/man "$PREFIX/share/man"
You might notice the extra difficulty caused by configuring users at packaging time, although more due to busybox choices and current systems heterogeneity.
I’d gladly live fine with /etc/qmail and /bin instead of /var/qmail/control and /var/qmail/bin, but two symlinks does the trick just fine.
Is formatting the man pages at compile time really necessary? The man command (and an nroff/groff/mandoc backend) is quite ubiquitous.
Neat, thank you for sharing your packaging script.
Is formatting the man pages at compile time really necessary? The man command (and an nroff/groff/mandoc backend) is quite ubiquitous.
It has always been true that not all platforms use or make available preformatted manpages (“catpages” with a .0 extension). qmail does absolutely install them, as you observe. One significant change that has occurred in the intervening years is platforms (e.g., OpenBSD) only supporting the mandoc macro package, and not the man macro package that the qmail documentation is written in. We can no longer assume or rely on the man macro package being available even when a platform otherwise has a working man command.
I would like to make building the documentation optional, which would make our build-time dependency on groff optional–without rewriting the man pages we’d still have a runtime dependency on an nroff that has the man macros (groff in most cases), so the question of whether to use the mandoc/mdoc macros (now more widely supported) immediately comes up.
Some of those questions won’t be decidable until we’re further along with FHS support, but this is an area where both practice and tooling have changed out from under qmail, and we’ll attend to that as it makes sense to do so.
I was about to suggest to provide the preformatted man pages in the release, but it might be better to be able to reproduce the entire thing everywhere.
As many of you know, I maintain the #lobsters IRC channel bot, Mock Turtle. That bot notifies IRC of story submissions to lobste.rs. It works by using the mailing list mode, and so runs an email server and converts incoming messages to IRC notifications.
I’m pleased to announce that, on the release of notqmail-1.07, the bot is using notqmail to receive these messages.
Some examples of feedback we’d welcome:
Hope to hear from some folks playing with this.
Congratulations on the release.
This begs a question I haven’t seen answered elsewhere though. What would be the reasons for a sysadmin to invest time and effort into (not)qmail? Other implementations (such as Postfix) seem to meet an equal standard of stability, while already providing the features you want to implement in notqmail.
For the moment, we’re targeting sysadmins who already run (net)qmail. Much later, when we begin to approach feature parity with Postfix, notqmail might start being an interesting alternative. We hope that time will come. If you can’t figure out why you’d run it right now, you’re probably right :-)
That makes sense, thanks :-)
We see new software popping out (on Github) and fading (on SourceForge) all of the time, but former software updated by different maintainers, not so often.
I bet it gives a different feeling this way, a sense of continuity.
This was the script I was packaging netqmail with.
You might notice the extra difficulty caused by configuring users at packaging time, although more due to busybox choices and current systems heterogeneity.
I’d gladly live fine with /etc/qmail and /bin instead of /var/qmail/control and /var/qmail/bin, but two symlinks does the trick just fine.
Is formatting the man pages at compile time really necessary? The man command (and an nroff/groff/mandoc backend) is quite ubiquitous.
The way I’ve packaged mail/qmail in pkgsrc (which is now notqmail-based), you get symlinks too:
We intend to address FHS/hier(7) more directly in 1.08.
In pkgsrc, I’ve patched out preformatted man pages. But for notqmail, we haven’t convinced ourselves that’s the best move. I think we’re not done noodling on how to handle docs.
Neat, thank you for sharing your packaging script.
It has always been true that not all platforms use or make available preformatted manpages (“catpages” with a .0 extension). qmail does absolutely install them, as you observe. One significant change that has occurred in the intervening years is platforms (e.g., OpenBSD) only supporting the mandoc macro package, and not the man macro package that the qmail documentation is written in. We can no longer assume or rely on the man macro package being available even when a platform otherwise has a working
mancommand.I would like to make building the documentation optional, which would make our build-time dependency on groff optional–without rewriting the man pages we’d still have a runtime dependency on an nroff that has the man macros (groff in most cases), so the question of whether to use the mandoc/mdoc macros (now more widely supported) immediately comes up.
Some of those questions won’t be decidable until we’re further along with FHS support, but this is an area where both practice and tooling have changed out from under qmail, and we’ll attend to that as it makes sense to do so.
I was about to suggest to provide the preformatted man pages in the release, but it might be better to be able to reproduce the entire thing everywhere.
Thank you for the description.