v0.5.6 — A window a launcher can find, and Arch's built from source

Roadmap item 0.5.6, and the last of the 0.5 milestone. Two gaps, both of which were written down rather than quietly left.

the desktop entry is valid
OK: on Arch the window builds from source, declares what it links against, installs with an entry a
    launcher can find, and comes off again

The window was invisible to the desktop it was written for

Installed, runnable from a command line, and in no launcher — because no package shipped a .desktop file or an icon. Every package that carries the window now carries both.

• The entry is validated by desktop-file-validate, before it is installed and again afterwards. A .desktop file with a mistake in it is one every desktop environment ignores in silence, which is the worst way for this to be wrong.
• The .rpm rebuilds the desktop and icon caches in %post; the .deb deliberately does not — Debian has dpkg triggers that desktop-file-utils and hicolor-icon-theme already own, so a package calling the tools itself would be doing the work twice. RPM has no equivalent.
• The icon is a plain mark: three flows crossing a lens, one of them stopped, drawn with four shapes so that it still reads at sixteen pixels. Nothing in the packaging depends on what is in the file, only on its name — it is there to be replaced by something better rather than defended.

Arch's window builds from source

Which is what the AUR is for, and the opposite of flowlight-bin beside it. On a rolling distribution it is the only shape that works: something linking against the system's GTK, libadwaita and glibc that was built elsewhere is something that may not start, and on Arch elsewhere means "last week" as much as "on Fedora".

CI builds it with makepkg from a git archive of the working tree, so what is built is the code in the change. It installs the daemon's package first — because the window declares that it needs it, and that declaration is one of the things being checked — then asserts that the declarations name gtk4, libadwaita and flowlight, that ldd finds every library, that it answers --version, that the entry and the icon are where a launcher looks, and that removing the package takes them away again.

The release renders PKGBUILD-gui against GitHub's own tag archive, so the hash in it is the hash of the file somebody will actually fetch rather than one computed from whatever tree happened to be checked out.

One trap found by running the renderer by hand

A tarball whose version did not match the one being rendered produced arch=(flowlight-0.5.3-x86_64) — a PKGBUILD wrong in a way makepkg accepts and no architecture ever matches. It is refused now, by name. And uname -m says arm64 where Arch says aarch64, which only the local modes could ever have hit.

Where Linux support stands

	daemon	window
Ubuntu, Debian	.deb	.deb
Fedora	.rpm	.rpm, built on Fedora
openSUSE Tumbleweed	.rpm	.rpm, built on Tumbleweed
openSUSE Leap 15.6	.rpm	— its libadwaita is older than 1.5
RHEL, Alma, Rocky	.rpm	from source
Arch	PKGBUILD	PKGBUILD-gui, from source
Alpine, Void, anything	tarball and install.sh	from source

Every row of that table is checked by CI on every push, inside a container of the distribution it names.