unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: vtkq2fqnxd@liamekaens.com
To: guix-devel@gnu.org
Subject: Estimated overhead of building an orthogonal Musl-based LFS within Guix build system
Date: Mon, 13 Feb 2023 00:10:57 +0000	[thread overview]
Message-ID: <29580-1676247058-115332@sneakemail.com> (raw)

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.


             reply	other threads:[~2023-02-13  4:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13  0:10 vtkq2fqnxd [this message]
2023-02-13 11:19 ` Estimated overhead of building an orthogonal Musl-based LFS within Guix build system Csepp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29580-1676247058-115332@sneakemail.com \
    --to=vtkq2fqnxd@liamekaens.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).