Skip to content

v0.5.3 — Arch, and a tarball for everything else

Choose a tag to compare

View all tags
@blessdyb blessdyb released this 01 Oct 00:52
· 36 commits to main since this release
v0.5.3
53ffb82
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Roadmap item 0.5.3. With this, every major distribution has a way in that is not "clone it and build it".

# Arch: the PKGBUILD from this page
makepkg -si

# Anything else: the tarball, which installs two files and says what it did
tar -xzf flowlight-0.5.3-x86_64-linux.tar.gz
cd flowlight-0.5.3-x86_64-linux && sudo ./install.sh
OK: on Arch Linux the tarball installs, does not enable itself, and comes off again
no systemd here, and the installer did not pretend otherwise
OK: on Alpine Linux v3.20 the tarball installs, does not enable itself, and comes off again
OK: on Arch the package builds, installs, declares nothing, does not enable itself, and comes off again

The PKGBUILD is rendered from a template

The file CI builds and the file somebody uploads to the AUR ought to differ in exactly one thing — where the tarball comes from — and the way to be sure of that is for the rest of the file to have one source.

  • CI renders it against a tarball on disk and builds it with makepkg, as a user it creates, because makepkg refuses to run as root and is right to. Then pacman -U, then the same checks the other packages get: Depends On: None, the binary runs, the unit is on disk, nothing enabled it, and it comes off again.
  • The release renders it against the published tarballs, with both architectures' checksums, in the one job where both exist.

/usr/bin rather than /usr/sbin on Arch: there the second is a symlink to the first, and installing into a symlinked directory is how a package ends up owning a path that moves underneath it. The unit's ExecStart=/usr/sbin/flowlightd resolves through the symlink.

The tarball, checked in Alpine

Four files: the daemon, its unit, an installer that writes to two paths and says what it did, and the licence.

It is installed in alpine:3.20 — no systemd, no glibc, nothing of ours packaged for it. That makes it the honest test of the claim v0.5.0 made: a kernel of 4.18 or later and nothing else.

On a machine with no systemd the installer writes no unit and says so, rather than leaving a file nothing will ever open — and it offers systemctl enable --now only where that would work. A suggestion that cannot run on the machine reading it is worse than no suggestion: it sends somebody looking for what they did wrong.

The uninstaller takes both files away and leaves the database alone, for the same reason the .deb and the .rpm do.

Three things found by writing it

  • An awk assignment on the command line may not hold a newline. Every awk refuses it, so the rendered source= and sha256sums= lines go through a file rather than through -v.
  • An Arch pkgver may not contain a hyphen. So CI builds the tarball as 0.0.0.ci, which also keeps the directory name inside it matching what the PKGBUILD looks for.
  • The installer was right and the test was wrong. Alpine has no /usr/lib/systemd, so no unit was written; the test demanded the file anyway. It now asserts the decision in both directions.

What a release carries from here

.deb and .rpm for amd64 and arm64, a tarball for each architecture with its sha256, and a PKGBUILD naming both.

Assets 11
Loading