[bug#45020] [PATCH 0/2] image: Add system field.

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> I understand the need for an easier way to create images.  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.
>
> 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.
>
> 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".

Agreed; I understand that this is a desirable level of abstraction.

> 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. The <image> record might not be the right
> location for that information but I cannot think of another one.

OTOH, I might want to cross-build a Novena image from x86_64, or I might
want to build it natively.  Perhaps what could be said is that a Novena
image can either be built natively on armhf-linux, or cross-built to
arm-linux-gnueabihf.  Perhaps we should encode this constraint rather
than a specific ‘system’ or ‘target’?  (I’m thinking out loud…)

Regarding ARM boards, do you think some additional abstraction is needed
to encode cross-cutting concerns that affect not just the partition
layout and choice of a bootloader, but also kernel build options, and
maybe options for some userland packages (are there examples of that,
though?)?

Maybe the best course of action is to add all this info to <image> until
we have a better idea, after all.

I guess I’m contributing more questions that answers.  :-)

Thanks,
Ludo’.