First, as always, thank you for your work @josch and for checking in with community members to enable different distributions and OSes to be easier to build and support. It’s really appreciated!
I’ve been doing a bit of work on Alpine & Chimera Linux for Pocket Reform as well as doing the Pocket work for NixOS recently, and was also involved in some of the later OpenBSD work, so I can comment from those three perspectives.
Firstly, I think that having Makefiles will be super helpful. I know this is a bit of a long shot, but packaging Makefiles which also work with bsd make would be very handy for portability (especially on BSD) when packaging reform-tools for other platforms. Most platforms also have gmake (GNU make) available so it’s not a show-stopper. Being able to specify DESTDIR= during install is extremely helpful as well, for all the use cases I mentioned as it is typically very easy to set this once to the correct output directory and know that the files will end up in the right place during package build. This avoids a lot of manual cp’ing and mv’ing.
Specifically for distros like NixOS (and GUIX as well, IIRC), they don’t conform to FHS for things like library, binary and header path locations, given the usage of a centralised store for packages/derivations. They do however do a good job of setting things like PATH, LD_LIBRARY_PATH and various XDG_ environment variables to help finding things like binaries, headers, libraries and data files when they are often under a /nix store directory. So, I would also suggest the where possible, assumptions around things being in /usr/lib, /usr/include etc. are checked - when these kinds of paths are hard-coded in scripts etc. it can mean manual patching is needed when building packages. One example of this would be the reform-handbook script, which opens the handbook (which is a really cool idea to package!) however the path to the handbook is hard-coded to /usr - that’s not where it will be on NixOS, for example. It might be better to find it in XDG_DATA_DIRS and then use that path as a more flexible approach which will accommodate things like NixOS or GUIX.
Other than that, it’s really helpful if the releases are in a git repository and tagged with semver version numbers. Most packaging tools deal really well with this pattern (especially Chimera Linux, and Alpine). It’s very helpful for NixOS too as it wants to build derivations for known/stable Git references to be able to ensure reproducibility. I’m fairly sure this is already your plan, though.
Thinking about udev rules, it would be also handy if the Makefile could install those, and ideally to an alternate path (not DESTDIR, necessarily) as some of the distributions mentioned use different udev implementations and the best directory to install these rules into may not be consistent between distributions or implementations (i.e. eudev vs udev vs systemd-udev). This one is very low priority, as I’m fairly sure that all these implementations at least have /etc/udev/rules.d in common so sticking to that might be an easy answer.
For building kernel modules, not every distribution uses DKMS to build things like reform2_lpc so it would be good if installing DKMS files could also be optional. If a distribution is not using DKMS I think it would be reasonable for a package to provide its own configuration for keeping the module updated with kernel changes/upgrades, but we should avoid cluttering packages with DKMS files which won’t be used by installing them by default in make install. Alternatively a variable to skip DKMS config install in make install could be handy.
initramfs-tools is another similar area that might require special handling between distributions. The initramfs-tools package is fairly Debian specific (but I do know of other distributions which use it), other distributions might be using things like dracut or home-spun tooling to build and update initramfs files, so it’s worth also considering not installing initramfs-tools configuration by default, or providing a way to avoid installing them with make install. Again I think it would be reasonable to expect packagers for other distros to carry the configuration for that distributions initramfs management tool in the package itself.
For systemd, I know reform-tools currently ships timer units and some services and it might also be worth providing an option to avoid installing those. Alpine & Chimera Linux for example don’t use systemd (OpenRC and dinit respectively). Gentoo also can optionally use OpenRC. So we could either not install those conditionally (via a flag or something again) or perhaps adding example sysvinit style files for other init systems to the project might be an option, and they could be installed with a separate make target. I think the most likely approach initially will be just disabling installing the systemd targets in install with a specific flag and then letting packagers for other distros also package their own init units.
For NetworkManager, this is similar to systemd in that not all distros use it, so if we could avoid installing the config file by default or make it able to be disabled, that would helpful. In many distributions it’s available as an option, but it’s also common to use things like iwd or connman instead, so additional handling in packages will need to take care of that for other distributions. I suppose it’s technically possible for Debian you could switch to connman or iwd or even using wpa_supplicant directly for WiFi management, so maybe as a long term thing the tools repo could carry different powersave configs (if needed, I’m not sure if this is a specific NetworkManager workaround we’re shipping) and the package could “do the right thing”.
This is everything I can think of right now so I help this is helpful! This is definitely not meant to be a list of things which need to be fixed before it’s possible to package reform-tools for other platforms, but it’s more a list of considerations which would definitely help make the packaging simpler and the packaging metadata smaller for other distros.
