Musl builds are not supposed to run on glibc systems, and most systems are glibc systems, so dynamically linking to musl for a universal package without a dependency on the musl package sounds wrong. Do you mean to package static builds?

(I do agree glibc is a major pain and I wish most systems were musl systems, but that's not the case.)

@FiloSottile yes! I did mean static builds. Rust currently (for now...) statically links to musl libc by default if you specify a *-unknown-linux-musl target. You can also pass -Ctarget-feature=+crt-static to force static linking to libc.

I looked at CI a bit more, and I believe the main changes needed would be to build libfuse-dev and libpcsclite-dev against musl. Alternatively, I suppose the mount feature could be disabled for deb packages?

Then once a cargo-deb config is added, after the cargo build step, it should be as simple as cargo deb --target ...

Edit: oops, you already generate debs :)

Hmm, the inability to provide rage-mount (and in-progress derivatives like #233) is a significant downside. I also note that you've only specifically asked the Debian packages to be linked against musl, but they are just a way of packaging the binaries; the same issue applies to the regular binary tarballs.

The ripgrep argument doesn't apply here, as we build our Debian artifacts on a relevant system (ubuntu-18.04), not Arch.

So I don't see a strong motivation to migrate over to purely-musl builds, but I don't have a problem with providing statically-linked -musl.deb packages alongside the dynamic glibc ones, and having those only include the rage and rage-keygen binaries.

My main questions then are:

• How would we make the difference between them clear to users who are just looking at the release page?
• What happens if a user tries to install both .deb variants at once?

To statically link FUSE, it sounds like changes to the underlying crate we depend on would be required (rather than just compiling libfuse-dev statically), based on this issue on the fuser crate (a fork with more progress, that I haven't migrated to yet): cberner/fuser#170

Also, I can't figure out why I thought rage-mount required libpcsclite-dev (which is the smartcard library required for YubiKey support). Maybe this was back when I was experimenting with native YubiKey support? In any case, I've confirmed I can build release binaries without it, so I'm removing it in #254.

Hm, when you build on ubuntu-18.04 that means it might fail to run on Debian Stretch, which uses a libc 3 minor versions older. Admittedly, stretch is not supported for too much longer, but once you presumably move to focal, the same issue will occur with Debian Buster. glibc is only backwards compatible.

I'm working on a GitHub action that will build and package binaries statically linking against musl. I will also probably add an image with openssl and such to link to, so I can add libfuse, and then it's a matter of fuser, so it may be a while before mount will work.

I believe an easy way to make the packages different and incompatible is to name one e.g. rage-musl and have them mark each other incompatible in the Debian config (and document the difference).

Hm, when you build on ubuntu-18.04 that means it might fail to run on Debian Stretch, which uses a libc 3 minor versions older. Admittedly, stretch is not supported for too much longer, but once you presumably move to focal, the same issue will occur with Debian Buster.

The reason Debian packages used Ubuntu 18.04 is because that's the minimum required version for cargo-deb. For rage 0.6.0 I built non-Debian binaries on Ubuntu 16.04 for better compatibility, but that's now also 18.04 because 16.04 is being dropped from GitHub Actions this month (it having reached EoL). It's unlikely that I'd bump those build environments until 18.04 is being removed.

I believe an easy way to make the packages different and incompatible is to name one e.g. rage-musl and have them mark each other incompatible in the Debian config (and document the difference).

That sounds reasonable. The musl version could probably be documented in the Debian config so it shows up in the right UI places. I think I'll hold off making musl binary tarballs though, at least until there's someone asking for them, to try and keep the number of release packages at a reasonable level.

The reason Debian packages used Ubuntu 18.04 is because that's the minimum required version for cargo-deb

Interesting, I looked at the cargo-deb repo but I couldn't find any documentation about this, I probably should change some other configs if this is the case, could you point me to where you learned about this so I can reference it in PRs to other projects please?

The musl version could probably be documented in the Debian config so it shows up in the right UI places.

Could you explain why you want the musl version documented?

I think I'll hold off making musl binary tarballs though, at least until there's someone asking for them, to try and keep the number of release packages at a reasonable level.

That seems reasonable

Interesting, I looked at the cargo-deb repo but I couldn't find any documentation about this, I probably should change some other configs if this is the case, could you point me to where you learned about this so I can reference it in PRs to other projects please?

Unfortunately I do not remember exactly, sorry. It's what I documented in #222, and I suspect that was from me encountering failures when trying to install or use cargo-deb on 16.04 due to incorrect package versions.

In any case, GitHub has removed the 16.04 build environment as it's now unsupported, so 18.04 seems like a reasonable base version.

Could you explain why you want the musl version documented?

Ah, sorry, I didn't mean that the version number of MUSL should be documented. I meant that the extended-description for rage-*-musl.deb should make a note of it being a MUSL build.