Re: DEP 17: Improve support for directory aliasing in dpkg
On Sat, 6 May 2023 at 19:51, Helmut Grohne <helmut@subdivi.de> wrote:
>
> Hi Luca,
>
> On Sat, May 06, 2023 at 04:52:30PM +0100, Luca Boccassi wrote:
> > 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 paint it this way, but it really used to just work until we got the
> /usr-merge. Indeed, debvm creates virtual machine images effectively by
> bootstrapping a filesystem from packages and turning the resulting tree
> into a file system image.
>
> * /proc, /sys, /dev are mounted by systemd. All you need to do here is
> create the directories and base-files does so.
> * /tmp is shipped by base-files.
> * user and password creation is not handled yet, but can be handled by
> something similar to systemd-firstboot.
> * Not sure what you mean with certs, locale and timezone. You can just
> install ca-certificates, locales and tzdata as part of the bootstrap.
> * The bootloader part for baremetal is kinda out of scope for
> bootstrap, which is why debvm side-steps this. You can also skip it
> for containers and build chroots. So it is one out of multiple use
> cases that needs extra work here.
>
> In a good chunk of situations, you can get just by without messing
> around. Well that is until we broke it via usr-is-merged. I concur with
> Simon Richter, that restoring this property is a primary concern.
>
> > 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.
>
> No, this misses the point. You can configure essential in a very limited
> environment. However, you cannot do so without the lib or lib64 symlink
> (depending on the architecture) and the bin symlink. This is so
> critical, that it cannot be deferred to some external entity. It must be
> part of the bootstrap protocol. There are some suggested ways to fix
> this (such as adding separate bootstrap scripts next to maintainer
> scripts), but nothing implemented.
>
> > 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.
>
> It's neat that you can solve your use case by breaking other people's
> use cases. This is not constructive interaction however. This kind of
> behaviour is precisely what caused so much conflict around the
> /usr-merge. What if I gave a shit for your use case? Denying the
> /usr-merge and just continuing unmerged as long as possible (as merging
> would break my use case) would be my strategy of choice. You can make a
> difference here by starting to recognize other people's use cases and
> proposing solutions in that merged world. And no, it's not "add duct
> tape to every bootstrap tool".
>
> So I really want to see a solution for the bootstrap protocol before
> moving the dynamic linker and /bin/sh to its canonical location. The
> current bootstrap protocol is kept on life-support by installing the
> usrmerge package by default. Dropping usrmerge from the
> init-system-helpers dependency as first alternative or moving the
> dynamic linker would break it. If I had a solution in mind, I'd
> definitely post it right here, but unfortunately I have not.
>
> Helmut
There is absolutely no need to be so aggressive. I care about both use
cases, but evidently you have formed a different view in your mind, so
nothing productive is going to come out of this subthread right now,
so I'll stop replying. It's off-topic anyway.
Kind regards,
Luca Boccassi
Reply to: