On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross 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é.