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

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

[vtkq2fqnxd]

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.

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.