On Sat, 6 May 2023 at 16:11, Simon Richter <s...@debian.org> wrote: > > Hi, > > On 06.05.23 21:28, Luca Boccassi wrote: > > [shipping usrmerge symlinks in packages] > > > In the far future I'd like for these details to be owned by image > > builders/launchers/setup processes rather than a package, but this can > > be discussed separately and independently, no need to be tied to this > > effort. > > Ideally I'd like to have this information in a single package rather > than distributed over ten different tools, especially as this is also > release and platform dependent. > > If possible, I'd like to go back to the gold standard of > - download Essential: yes packages and their dependencies > - unpack them using dpkg --fsys-tarfile | tar -x > - install over this directory with dpkg --root=... -i *.deb > > to get something that works as a container. Right now, that only works > if I remove "init" from the package list, which is fair since a > container doesn't need an init system anyway. > > The less an image builder needs to deviate from this approach, the > better for our users.
To have a working system you need several more steps that are performed by the instantiator/image builder, such as providing working and populated proc/sys/dev, writable tmp/var, possibly etc. And it needs to be instantiated with user/password/ssh certs/locale/timezone. And if it needs to be bootable on baremetal/vm, it needs an ESP. And then if you have an ESP and want to run in a VM with SB, you'll need self-enrolling certs on first use or ensuring the 3rd party CA is provisioned. And then... You get the point. Going from a bunch of packages to a running system necessarily has many steps in between, some that are already done and taken for granted, for example when you say "works as a container" I'm pretty sure the "container" engine is taking care of at the very least proc/dev/sys for you, and it's just expected to work. bin -> usr/bin, sbin -> usr/sbin and lib -> usr/lib should get the same treatment: if they are not there, the invoked engine should prepare them. systemd and nspawn have been able to do this for a while now. Not having those hard coded means that the use case of / on a tmpfs with the rest instantiated on the fly, assembled with the vendor's /usr and /etc trees, becomes possible, which is neat. And said trees can pass the checksum/full integrity muster. Kind regards, Luca Boccassi
