Re: DEP 17: Improve support for directory aliasing in dpkg
On Sat, 6 May 2023 at 16:11, Simon Richter <sjr@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
Reply to: