Hi, I'm the maintainer of binfmt-support, which makes it easier to manage the binfmt_misc facility of the Linux kernel to register interpreters for additional binary formats; it's designed so that other packages can drop in binary format files to declare what they support, and that sysadmins can use the update-binfmts tool directly. It's been in Debian for somewhat over ten years, and various packages there make use of it. There is a bit of an overlap here with systemd's binfmt facility for those who are using it, but I believe they can coexist reasonably peacefully, and binfmt-support is more powerful: as well as being better-designed for use by packaging, it can assist with the situation where telling the difference between different file types requires more intelligence than the binfmt_misc registration mechanism can offer (for example Wine vs. Mono). An ebuild is attached. I guessed at sys-fs as an appropriate location, but of course feel free to correct that as appropriate. I've done my best to set it up with appropriate init system configuration: I already had systemd, and I issued a new upstream release with an OpenRC script as part of preparing this ebuild. I haven't actually been able to boot-test this as I'm afraid I only have Gentoo installed in a chroot; but writing OpenRC scripts looks straightforward enough so I don't think I can have got it too badly wrong. Reproducible: Always
Created attachment 369840 [details] binfmt-support-2.1.2.ebuild
Bumping to 2.1.3; I converted my Gentoo chroot to a Xen domU so that I could actually boot-test this, and found an embarrassing bit of reversed logic in the OpenRC script, so I issued a new upstream release to fix this.
Should I be adding a postinst to recommend that the user calls rc-update, or perhaps even do it automatically (I'm not sure of the Gentoo policies here)?