Use config file instead of update-binfmts for binfmt support

[TheAssassin]

Follow-up for #24.

Currently, binfmt-support packages are only available on Debian platforms. @NuLogicSystems brought up an alternative: use config files as described in the freedesktop standard. They should work out of the box with all systemd based distros. We just need to restart a service, as it seems, unless the system has some hooks for binfmt support in their package management system, which will have to be tested on the distros listed as supported in the README.

[TheAssassin]

@NuLogicSystems you said in #24 that you have checked some packages which use these config files. I'd like to see how they did it, too, but all the packages I got from the Arch mirrors (mostly Java) don't contain such files. Could you tell me which packages you inspected?

[NuLogicSystems]

I checked Arch, Suse, Mageia, Fedora, you have to click the file list button to see them.

In the case of Arch, look in the pkgbuild file, and at the conf files themselves:
https://aur.archlinux.org/cgit/aur.git/tree/?h=binfmt-qemu-static
https://aur.archlinux.org/cgit/aur.git/tree/?h=binfmt-java

There are no binfmt related packages in the official repositories, what were you looking at exactly?

[TheAssassin]

I was checking the wrong packages, apparently. At least I am doing it right for AppImageLauncher, looking at these packages. And there seems to be a binfmt hook that restarts systemd-binfmts in pacman, which is good to know, too.

[NuLogicSystems]

Yes, I saw that as well.

[TheAssassin]

I wrote and tested a config file:

# Launch AppImages with AppImageLauncher
:appimage-type2:M:8:414902::@CMAKE_INSTALL_PREFIX@/bin/AppImageLauncher::

Works fine. However, there's some unwanted side effects.

First of all, on Debian, the maintainer scripts have to systemctl restart systemd-binfmt manually. On installation, it installs the binfmt support perfectly fine. On removal, however, the config remains enabled, leading to broken system behavior. AppImages can't be run any more. update-binfmts --remove <...> however unregisters the format perfectly fine, as it communicates with the kernel.

On systems without systemd (or, rather, systemd-binfmt command), the binfmt support wouldn't be set up any more.

IMO we should continue to bundle and set up binfmt support with binfmt-support's update-binfmts command, at least on Debian/Ubuntu, where a binfmt-support package is available we can depend on.
On other systems (namely RPM and Arch), we need to check whether installing the file into /usr/lib/binfmt.d will work as intended. If not, we should continue to bundle update-binfmts for RPM packages. On Arch, there is no such package, therefore we should just bundle the config I posted and check whether we need to manually restart systemd-binfmt.

[NuLogicSystems]

Well yes, systemctl restart systemd-binfmt would need to be run again on removal of the package.

Question, how does the existing hooks work?
Is there a hook to run systemctl restart systemd-binfmt on removal (after conf files are removed).
If one doesn't exist, we may need to provide our own hook specifically for our package.
Otherwise, on arch the config wouldn't be disabled until after a reboot, Arch restarts this service on boot by default.

[TheAssassin]

Is there a hook to run systemctl restart systemd-binfmt on removal (after conf files are removed).

In my example package, there was, yes. I even restarted it manually after removal of the file. It didn't work as intended. But that might be an issue on Debian only.

Please check #27.

[NuLogicSystems]

Question, is cmake installing the files to the proper location, or do we need to do it in packaging?

[NuLogicSystems]

OK, I just looked at your code and it doesn't look right.

[TheAssassin]

Why doesn't it look right?

The config file is installed into /usr/lib/binfmt.d. See https://github.com/TheAssassin/AppImageLauncher/pull/27/files#diff-87364c4677e09f50088671831b8ad597R64.

In the install hook, it is now checked whether update-binfmts is available, either on the system or bundled. Otherwise, the script restarts the systemd-binfmt service. https://github.com/TheAssassin/AppImageLauncher/pull/27/files#diff-48ec4b1ac96b51dfe488c7d15ab99605R24

[NuLogicSystems]

It should be a post-uninstall script, not a pre-uninstall script, as the config file would still exist under /usr/lib/binfmt.d, and in reality, restarting the service at that time would do nothing.

[NuLogicSystems]

In debian both methods are available, so if it's looking for update-binfmts, that is what it will use. And since it was done outside the systemd service, restarting the service would do nothing.

[TheAssassin]

and in reality, restarting the service at that time would do nothing.

That's right, I'm restarting the service at the wrong place. I'll switch to post-uninstall scripts.

However, as described above, I even restarted the service manually after uninstallation, and the association didn't get removed. Can you explain why?

[NuLogicSystems]

Ill take another look, but binfmt-support uses initd scripts (non systemd method) for starting and stopping, aka the old method. That is unless you uninstalled binfmt-support prior to installing your package.

[NuLogicSystems]

OK, actually it's using it's own systemd service not the one bundled with systemd