This didn't end up being something that's being worked on. It probably
was entirely confusing for everyone as it wasn't documented, and didn't
actually do anything useful most of the time.
Rather than polluting the build with some one-off special cases like
this, we'll implement an "installer" as an example system, if we even
want an installer.
It's not planned yet *how* users should install, it may not even be an
installer type system.
This also rewords the "successful default build failure" message.
This quirk touches the `blank` file of the framebuffer /sys nodes, which
ends up unsuspending things that start suspended until the *right thing*
is happening to not be suspended.
X11, among others, do the right things. It seems other framebuffer
interfaces are not.
This can likely be fixed in other ways, but this is the more
approachable way to me right now.
Instead of borrowing some of its system.build products, rely instead on
a full system.build for the recovery.img.
This allows us to better make use of the implicit declarativeness of the
system configuration. At some point the recovery "system" will be moved
out of that file and things will continue to work.
This ends up saving ~100KiB. Not much, but we're already 1MiB over the
~7-8 MiB budget.
Though, in reality, it's not for the space saving, but because
dlopen/dlsym will be needed for ffi-based bindings.
In addition, put the implementation of the build side-by-side with the
system type definition. It made no sense to keep those where they were,
as it was baggage from the earlier implementation of the project.
It didn't make sense to stuff that into systems anyway, it's baggage
from the first steps of making Mobile NixOS.
This is a *part* of depthcharge system type, so why stuff it into `system`
at the root??
It didn't make sense to stuff that into systems anyway, it's baggage
from the first steps of making Mobile NixOS.
This is a *part* of android system types, so why stuff it into `system`
at the root??
From https://hydra.nixos.org/eval/15817511580f35dfb accidentally introduced udisks
in the build.
A local test build of the default "dummy" system disk image wasn't done,
thus the failure not found.
This quirk assumes the firmware has been set appropriately in the NixOS
configuration, using something akin to:
```
hardware.firmware = [
pkgs.my-device-firmware
];
```
That new option allows us to remove the crutch of pretending to be a
container.
Pretending to be a container had a couple drawbacks, they are now
irrelevant.
The dummy outputs could be re-worked to instead use out own stage-1
infra, but I prefer using dummies for now, for better insulation.
We are now splitting the concerns more clearly, by making `baseModules`
the reason we are evaluating NixOS, rather than wholesale always
including it into the modules.
