Re: Estimated overhead of building an orthogonal Musl-based LFS within Guix build system

[Csepp]

vtkq2fqnxd@liamekaens.com writes:

> Hi,
>
> I'm wondering what the overall estimated work or effort might look
> like to leverage Guix to build a co-existing family of packages that
> are in some sense "orthogonal" to the rest of Guix, based upon
> different package versions and perhaps musl libc - similar to
> https://github.com/dslm4515/CMLFS for example.
>
> Could a series of such packages be built up in the same way that these
> LFS type builds bootstrap themselves? For example, starting with the
> most primitive dependencies and going on upward.
>
> For this to work, different package versions for the same kind of
> package would need to coexist - which I don't believe is inherently a
> problem. But also, these builds would need to refer exclusively to
> paths and prefixes that are wholly self-contained and orthogonal to
> the rest of Guix.
>
> The overall aim here is to consider building some select packages for
> example with musl libc, or perhaps building a "stable track" of
> software that is unaffected by the rest of Guix evolving packages.
>
> The measurement of effort can be subjective. Perhaps it involves
> modifying existing recipes and adapting these to point to different
> packages/versions. Maybe there is a similar precedent somewhere.
>
> Any thoughts are appreciated.

I would love to see this but similar ideas have already come up (eg.:
BSD port) and the response from core contributors (based on experience
with Nix) was that maintaining multiple libc's is not worth the effort.

I would definitely want a more Alpine-y Guix though.