======================= 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. ---- :Date: 2022-07-21