Re: [PATCH] Add image configuration option

["José Pekkarinen" <jose.pekkarinen@unikie.com>]

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

On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross <hi@alyssa.is> wrote:

> [...]
> Okay, thanks for the explanation.  I think we can group some of these
> together:
>
>  • Stuff that's already Nixpkgs configuration options or can be
>    expressed through an overlay.  Whether to cross compile, what
>    architecture to build for, whether to use a vendor kernel, etc.  This
>    can already be handled through the existing configuration mechanism.
>
>  • VM customisation, including extra VMs, disabling Wayland, etc.  In my
>    mind there are still some open questions around how this should be
>    implemented exactly, but this is definitely something that needs to
>    be more configurable.
>
>  • Whether to install extra stuff on the host system.  This covers
>    things like debugging symbols and tools.
>
> Does that sound right to you?  Are there more that you can think of?
> I'd like to understand the requirements here better, to help think about
> what sort of configuration mechanisms might be required.
>

This is a good summary, currently I can think of a coupel of more,

which is a mechanism to provide upstream project configuration artifacts
when nix allow to bypass their automated configs, for example, a kernel
config when using manual config kernel nix package, a bit more unclear
is how to provide upstream configs when nix is not flexible enough. A
mechanism to generate a full image from the nix generated artifacts putting
together kernel, initrd, rootfs and ext partition so that the full image can
be flashed in a sdcard of choice and use it. This would require to be
configurable so that you can modify the partition table to suit vendor
needs.

[...]
> You're right — it's generally a bad thing if people have to patch
> Spectrum to make it fit their needs.  I want to avoid that.  But most of
> the things we've talked about so far don't feel to me like they're going
> to lead to massive configuration files.  The exception is all the stuff
> that's either Nixpkgs configuration or overlays, but the mechanism you
> proposed here wouldn't help with that, because only a single
> configuration file would be able to change anything in "pkgs", due to
> the configuration files being merged using the non-recursive //
> operator.  That's exactly why it's important to understand what the
> needs are before we consider specific configuration mechanisms.  It's
> difficult to figure out if an idea will actually make things easier
> without seeing an example of the problem, and what difference to it the
> proposed solution would make.
>

Well, the exact point of that is to give you a small next step to move

towards a more flexible configuration system, without loosing control
to revert back if the situation doesn't look better. It is unlikely a more
complex contribution would be acceptable for you if even a little one
like this wouldn't make it.

José.

[-- Attachment #2: Type: text/html, Size: 4110 bytes --]