Note that currently there are 3 commits in this PR. However, two of them are from other PRs, and shouldn't be included when this is merged in.

This PR should only be merged in after the following two have been merged in:

• dbus: enable building with musl #71560 (4845af0) enable building dbus with musl. dbus is a dependency of cups.
• libusb1: enable compiling with musl #71563 (b1b809f) enable building libusb1 with musl. libusb1 is a dependency of cups.

The only commit that is relevant to this PR (well, cups), is 317cd4d.

@GrahamcOfBorg build cups

@GrahamcOfBorg build pkgsMusl.cups

This is related to the following three PRs:

• dbus: enable building with musl dbus: enable building with musl #71560
• libusb1: enable compiling with musl libusb1: enable compiling with musl #71563
• vte: enable compiling with musl vte: enable compiling with musl #71577

Systemd /should/ build on Musl right? Perhaps some patch exists for it?

@matthewbauer As far as I am aware, it is difficult to get systemd to build with musl:

https://github.com/NixOS/rfcs/blob/master/rfcs/0023-musl-libc.md#big-incompatibilities

I think @nh2 has done a lot of work getting stuff building in pkgsMusl. Maybe he can say something about systemd?

Feedback to things like https://lists.freedesktop.org/archives/systemd-devel/2014-September/023177.html was mostly constructive IMHO.

I think in general systemd upstream seems to be fine with accepting patches enhancing musl compat, it might be just more complicated if it's about things not provided by the libc, if there's different opinions on whether it should be in there or not.

Another thread from systemd/casync: systemd/casync#129 (comment)

That being said, removing systemd in case of building with musl might be a good workaround for now, but having a musl-based systemd might become interesting for NixOS-on-whatever-device setups :-)

This has the 10.rebuild-linux: 2501-5000 tag. Would it be better to go into staging?

On the point of systemd + musl compatibility:

Upstream support for making systemd support building on musl is mixed.

systemd maintainers are mostly of the opinion that they should use glibc functions they consider useful, as opposed to re-implementing them (code duplication) to support other libcs.

I think one could say they consider glibc a more of a "normal library dependency" that provides the functions they want, and not a "minimal portable standard".

On the functions that systemd uses that glibc has and musl does not, the opinions diverge on whether they are are useful or good to have in a libc.

I personally forecast that systemd and musl slowly get together over time, but don't expect that this is very soon, so I think the approach in this PR to disable it for now is exactly the right choice.

@cdepillabout Another request across your 4 PRs (not a blocker but a nice-to-have):

Could you make enableSystemd ? (stdenv.isLinux && !stdenv.hostPlatform.isMusl) a parameter (top-level argument) of each package?

That would allow us to easily turn off systemd deps even when using glibc, which would be convenient to quickly check whether things are fine with glibc in situations where the musl builds are broken. It would also be in line with how other packages are written.

Could you make enableSystemd ? (stdenv.isLinux && !stdenv.hostPlatform.isMusl) a parameter (top-level argument) of each package?

This has been done in 3a4584c. Thanks for the suggestion!

@GrahamcOfBorg build pkgsMusl.cups

This has the 10.rebuild-linux: 2501-5000 tag. Would it be better to go into staging?

I've force-pushed a slightly reworked version of the patch that keeps the original order of buildInputs, so that on non-musl, this should not create any changes.

@nh2 Didn't realize this was the thing forcing the mass rebuild! Thanks for catching and fixing this!

Rebased on master

This has worked fine for me in static-haskell-nix so far, and no changes for non-musl; merging.

@nh2 Thanks for fixing up these four PRs and merging them in :-)