unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: 45020@debbugs.gnu.org
Subject: [bug#45020] [PATCH 0/2] image: Add system field.
Date: Sun, 13 Dec 2020 15:59:13 +0100	[thread overview]
Message-ID: <20201213155913.7022f5ee@scratchpost.org> (raw)
In-Reply-To: <87h7orpgsh.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

Hi,

I want to note that there's a difference between cross-compiling things
and natively compiling things (even if only qemu transparent emulation).

The resulting images between cross vs non-cross could be (and probably are)
different.

So I think there should be a command line parameter to the image script that
specifies whether to cross-compile or not--there's no way around it that I can
see.

Also, this image generation thing is mostly for bootstrapping Guix, so it is
fine if that only supports configurations we actually tested.

Ludo said:

> > However, I
> > feel like <image> is the wrong place for ‘system’ and ‘target’: the
> > image format, conceptually, has nothing to do with whether we’re
> > cross-compiling, compiling for a specific system, etc.  

It depends on what you mean.  How the word "image format" is colloquially used
in the VM world, it very much has to with what guest system (and even which
emulator) this image is for, and that's not at all variable.

But I agree that there are other things that could be variable per image target
system, like the kernel version that actually works, the u-boot that actually
works, the partition layout that actually works, the initrd modules, weird
system packages and/or activation scripts that are required for booting etc.

See buildroot.

Mathieu said:

> On the one hand, I agree that adding "system" and "target" to <image>,
> so that they can override the corresponding arguments doesn't feel
> nice. On the other hand, I think that dealing with system/target is too
> low level for most users.

I agree.  Also, I want to stress that if we do this kind of image generation,
it has to be for Guix images we actually tested.  So the general case with
specifying a random system and target we never saw before cannot be supported
anyway (and will likely not work), especially since bootloaders are anything
but portable in general.

> When using Yocto, Buildroot or even OpenWrt, you say "build me an image
> for that board/machine" and not, "build me an image for that board by
> cross-compiling to this mysterious triplet".

I agree that we should not ask the user to specify a triplet to build a guix
system image.  It's obvious what the triplet is per image, since we tested
it anyway (riiiight?).

> If the user selects the image type "pine64" or "novena", it's obvious
> that the image has to be built for ARM, so I think it makes sense to
> hardcode it somewhere. 

I agree.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      parent reply	other threads:[~2020-12-13 15:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 10:53 [bug#45020] [PATCH 0/2] image: Add system field Mathieu Othacehe
2020-12-03 10:53 ` [bug#45021] [PATCH 1/2] " Mathieu Othacehe
2020-12-03 20:41   ` Danny Milosavljevic
2020-12-04  8:12     ` Mathieu Othacehe
2020-12-04  9:01       ` Danny Milosavljevic
2020-12-05 10:24         ` Mathieu Othacehe
2020-12-03 10:53 ` [bug#45022] [PATCH 2/2] image: Rename "raw" image-type to "efi-raw" Mathieu Othacehe
2020-12-03 13:11 ` [bug#45020] [PATCH 0/2] image: Add system field zimoun
2020-12-09  8:25 ` Efraim Flashner
2020-12-09 10:15   ` Mathieu Othacehe
2020-12-09 10:27     ` Efraim Flashner
2020-12-11 16:50 ` Ludovic Courtès
2020-12-12  8:30   ` Mathieu Othacehe
2020-12-12 12:34     ` zimoun
2020-12-13 14:15       ` Ludovic Courtès
2020-12-15 14:11         ` zimoun
2020-12-15 21:56           ` Ludovic Courtès
2020-12-12 17:51     ` Ludovic Courtès
2020-12-15  9:58       ` Mathieu Othacehe
2021-07-16  2:04         ` Maxim Cournoyer
2021-08-30 16:24           ` Mathieu Othacehe
2021-10-05  8:26             ` Mathieu Othacehe
2021-10-11 12:06               ` bug#45020: " Mathieu Othacehe
2020-12-13 14:59     ` Danny Milosavljevic [this message]

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=20201213155913.7022f5ee@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=45020@debbugs.gnu.org \
    --cc=othacehe@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).