=======================
Packaging and logging
=======================
For a while now I wanted to package all the work-related software into
deb packages properly, with the dependencies just on packages from
regular Debian repositories (and each other, in some cases). I used to
build binary-only packages with ``cabal copy`` before, but it doesn't
work with Cabal 3 (the software is in Haskell), so I decided it's the
time for another attempt to package everything.
I already knew that there still are unmet dependencies: a while ago
wrote all those down, then worked on eliminating those, but a few were
tricky to get rid of, so I figured I'd try packaging them too.
The first among those dependencies is ``libsystemd-journal``, the
bindings for logging. It came with its own unmet dependency, on
``unix-bytestring``, and the required versions of its other
dependencies had to be adjusted (relaxed) in order to build it. That's
a bit awkward, and once again made me to wonder about removing this
dependency, since it's also Linux-only, harming the overall
portability. I used it instead of syslog because of structured
data/fields, which are handy; the newer syslog protocol (RFC 5424)
actually supports them too, but rsyslogd doesn't accept those by
default, apparently systemd's journald does not handle that format
either, while the POSIX syslog(3) only aims RFC 3164, glibc is not
going to provide an additional function or anything of the sort. I
could implement RFC 5424 log writing manually, but then it'd be just a
mess if it'll be written into a syslog daemon that doesn't handle it,
which is the default on Debian now. Every solution comes with its own
awkwardness.
Then there are MySQL and AMQP bindings. I didn't try to package those
yet, but for some years now we're in the process of moving from MySQL
to PostgreSQL (which I'm rather happy about; picking PostgreSQL over
MySQL since at least 2008), and AMQP message queues can easily be
replaced in this case, with PostgreSQL's LISTEN/NOTIFY for
asynchronous notifications, or even simply removed. Unclear how long
it'd take though. After packaging, I thought of also proposing to add
those packaged dependencies into Debian repositories, but adding the
ones that I probably won't need myself by the time they'll make it to
"stable" seems wrong.
And then there's the ``cron`` package, which helps to schedule tasks
based on the crontab format. Though I currently can't install
dependencies for that, since I happened to begin this in the middle of
Debain sid/unstable transition to a new GHC version (meaning that many
packages in the repositories are broken, referencing dependencies
which aren't there), and proper initial packaging only aims sid,
failing on stable or testing (so I'm using a chrooted sid for
that). So I decided to just write it from scratch; it was easy, but
I've used ``dayOfWeek`` from the ``time`` package, which was added
just in a newer version, so had to update the package database on an
older system where it had to be deployed, which didn't go smoothly:
among other dependencies is ``cryptonite`` (a consequence of depending
on ``http-client-tls``), which dropped support for GHC 8.0 in its most
recent version, so I had to install it with a manually provided
version constraint. Maybe next I'll work on moving from
``http-client`` to ``curl``: switched from ``ftphs`` to ``curl``
elsewhere already, because of similar versioning- and
dependencies-related issues, and the curl bindings have minimal
Haskell dependencies. Although the ``amqp`` library depends on
``connection``, which pulls all the TLS stuff anyway.
And all that juggling with dependencies is on top of juggling dozens
of external network protocols on one side, and 3 to 6 (depending on
the counting method and external device/protocol type) internal
configuration and data formats/databases on the other.
Now I'm thinking of giving up on structured data logging, and using
the basic RFC 3164 syslog; possibly switching to the RFC 5424 variant
if/when it'll become supported at least by rsyslogd out of the box. Or
maybe will just leave things as they are for now.
