Source of udev rules is confusing

[VincentVanlaer]

The udev rules can be found in multiple locations, namely the mooltipass-udev repository and data/moolticute.sh, but not as a separate file in this repository. Therefore, following the build instructions does not install the udev rules. This has led to different package maintainers doing different things:

• The debian package fails to build, unless they are explicitly downloaded from the mooltipass-udev repository.
• The Fedora package downloads the udev rules from a specific commit (which has the risk of becoming stale) on the moolticute-udev repository.
• The AppImage (and the NixOS package) extracts them from scripts/moolticute.sh. Again, this requires manual updates.
• For Arch Linux, there are two packages: moolticute and mooltipass-udev.

I think at least the AppImage should be fixed to use the udev rules from the mooltipass-udev repository (same for the NixOS package, but that should be fixed on their side, not here). However, it might better if the udev rules were contained within this repository, which would simplify packaging. The disadvantage I see is that you can't install/update the udev rules separately from moolticute, as the Arch Linux package allows.

Some context might be necessary for why I encountered this:

• I was trying to have the Exec path in moolticute.desktop be generated during builds, so that it can include the install prefix.
• The required both modifying the Makefile in the root of the repository as well as daemon.pro. This seemed somewhat weird to me as qmake generates a Makefile which also contains an install target. After some searching, it seemed that the Makefile was only used for the Ubuntu debs on launchpad. I don't think it makes sense then for the Makefile to live in the root of the repository.
• As debhelper is capable of working with qmake without much additional configuration, it turned out the Makefile wasn't even necessary to build the debian package (which some small modifications to debian\rules), with one exception, the udev rules, hence this issue. Having the udev rules in this repository would help in cleaning up the debian build process, and remove the duplication between qmake, the Makefile and other package building scripts.

Thoughts?

[principis]

The Fedora package downloads the udev rules from a specific commit (which has the risk of becoming stale) on the moolticute-udev repository.

I was in the progress of splitting the udev rules to a separate mooltipass-udev (as should have been done in the first place) this is now finished.

[limpkin]

@raoulh do you remember why we chose to put the udev rules in a separate repo?

[bobsaintcool]

It all started as a single repository into my github account for packaging in Arch Linux. Then it was needed on other project I have but where I didn't wanted to pull moolticute because it was not following our usage. Eventually we moved the repository into moolticute org so you could have more control over it.

At that time there were also couple of other project that needed it without depending on moolticute: one cli tool in python and something in go from @raoulh I believe. I honestly liked the simplicity of hacking when you got a dedicated package / repository per task. So probably there were some opiniated drift of mine.

I'm not 100% familiar on how Debian package are generated but it seems to me that we decided at some point to follow two different concept:

• The debian package script are built into moolticute as kind of monolith
• The udev rules was built with the idea to have things splited in the smallest unit possible

I will say both approach have their pros and cons. That is being said I'm 100% on the split.

If I well understand your point @VincentVanlaer can I ask why we want to have Debian package script into moolticute into the moolticute project?

• Why not on other repository / location?
• If we want Debian script here, why not the one from other distro?

We can also pick another architecture which is one followed by systemd. Most of the code is on the same repository but we still have different packages.

On the Arch Linux side I believe we can pin a version of the mooltipass-udev into the moolticute dependencies like https://wiki.archlinux.org/title/PKGBUILD#Dependencies would it help you?

[limpkin]

ohhh that makes sense, thanks for the explanation!

[limpkin]

ping @VincentVanlaer

[VincentVanlaer]

I don't really have a strong opinion on which solution is ultimately chosen, that's up to those who do the actually packaging. As @principis already mentioned, the fedora package is in line with the Arch package now, which is good. As I said in the issue description, my main concern is that the scripts for the appimage have the udev rules embedded rather than letting the packager provide them (or downloading them automatically as part of the build). But solutions for that depend on what the preferred location of the udev rules is (separate repositories or single repositories).