the way this should work conceptually is that the live image contains an
@flatpak subvolume which acts as sideload directory created via flatpak
create-usb during the build.
currently we never install the sideload since I am unsure how to best
get it into the target system without actually moving the subvolume
there and consuming space needlessly
so.... technically we don't need this because supposedly glibc can load
defintions on-demand. more importantly though we generate all locales as
part of the image build already, so generating them again seems
pointless.
note: localecfg only generates the locales, the locale module is what
sets it up (supposedly). we still use the latter
Fixes#17
this is a bare minimum guessmitation. in reality we'll probably want a
ballpark of 10G per image, with up to 3 in flight. going with 40G for
now so there's some space for user stuff as well. plus ESP needs space
too
this isn't fully ready yet, but the plan is to have the debug tarball
consumable as part of sysupdate and then have the generator
automatically pick it up when booting
(I hope)
so the conflict between where snaps are mounted isn't really solvable in
a trivial matter so recursive bind /snap into the /var location expected
by the AUR build. this way things should start working properly
the arch snapd wants /var/lib/snapd/snap the snap snapd wants /snap.
link the former to the latter and maybe that will get us going.
we cannot not have /snap because then the snap snapd will error out on
uncreatable /snap. symlinking the other way around also didn't work in
testing.
as it turns out the AUR build of snapd explicitly builds with a
different path for snaps. to make things work that way and match snapd
expectations we now mount the snap volume into /var/lib/snapd/snap
(which is created during rootfs creation).
we also symlink /snap there so to the user everything seems as though it
was under /snap
if that doesn't work out we might have to reconsider using the AUR
package :\