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 artifactswhen 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 controlto 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.