Hi Santiago, Quoting Santiago Vila (2019-03-13 13:50:11) > On Wed, Mar 13, 2019 at 01:15:02PM +0100, Johannes Schauer wrote: > > I'm not advocating for doing "hacks here and there so that bootstrapping > > tools > > work properly" as you put it but that we think about the question of whether > > maybe there is a better way to populate an empty directory with software > > components that does not require as much magic as currently has to be > > supplied > > by tools like debootstrap. The result would not be "hacks here and there" > > but a > > cleaner and more robust setup procedure. > > > > So what I want you to take away from this long mail is: maybe we should > > re-think the way we are currently creating a Debian chroot because maybe > > there > > exists a different approach that would give us benefits that are actually > > important to our users and make maintaining the universal operating system > > easier? > Sounds good in theory, but I'd like to know what kind of new architecture are > you thinking of, how would it be implemented, or how would it work in > practice.
I assume by "architecture" here you don't mean Debian architecture but are
talking about the architecture that would improve on the current situation? I
already linked to two examples of approaches. I think in essence we somehow
have to manage the maintainer scripts.
One way would be support for chrootless maintainerscripts. Helmut filed #824594
against src:base-files but the maintainer was not convinced about the merits of
the approach and wanted to see some data about how a debootstrap-like tool
could take advantage of it. This was indeed my main motivation to write
mmdebstrap: to show that the approach was viable. Honestly, only now that I was
reading #824594 again, I realize that we are back at src:base-files talking
about the same topic that got me to write mmdebstrap in the first place. :D
Another way would be replacing maintainer scripts by more declarative
approaches, like pointed out by Guillem. I like this method a lot and it does
not conflict with the chrootless method which is still useful in situations
where one wants to (for example) create either a foreign architecture chroot or
create a chroot without needing superuser privileges.
And yet another would be, to allow dependencies between Essential packages or
by defining a package set even smaller than current Essential. But I like this
version the least.
> For example, for people bootstrapping new architectures, we introduced
> build-stages (afaik now called build-profiles). (The <!nojava> in gettext,
> for example).
Build profiles are for bootstrapping in the context of building software
packages. Here, we talk about bootstrapping in the context of debootstrap
where we bootstrap a directory filled with unpacked binary packages from
"zero". The arguments brought forth here only concern bootstrapping new
architectures in so far that an Essential:yes set with less maintainer scripts
makes bootstrapping a new architecture easier.
> Maybe in the same line we could add a special Depends field only meaningful
> for bootstrapping tools? Is this the sort of thing you have in mind?
>
> I would certainly consider a lot cleaner to add a new field to base-files in
> the form "Bootstrap-Depends: base-passwd" than converting all chowns in
> postinst to use integer numbers.
I agree that we should not expect maintainers to write numeric user and group
ids into their maintainer scripts. This is not only hard to write but also hard
to read and maintain. In my opinion, using numeric ids should only be a
temporary measure until we have a declarative method or other helper that does
the correct translation instead. But since no such helper exists right now,
numeric ids are probably the best way to fix this bug for buster.
I was now als able to trigger this bug in mmdebstrap. Here is how to populate a
chroot directory with a set of packages that is less than the Essential:yes set
and based on busybox:
sudo mmdebstrap --mode=root --variant=custom \
--include=dpkg,busybox,libc-bin,base-files,base-passwd,debianutils \
--setup-hook='mkdir -p "$1/bin"' \
--setup-hook='for p in awk cat chmod chown cp diff echo env grep less ln
mkdir mount rm rmdir sed sh sleep sort touch uname; do ln -s busybox
"$1/bin/$p"; done' \
--setup-hook='echo root:x:0:0:root:/root:/bin/sh > "$1/etc/passwd"' \
--setup-hook='printf "root:x:0:\nmail:x:8:\nutmp:x:43:\n" > "$1/etc/group"'
\
unstable ./debian-unstable-busybox
As one can see, I had to create a minimal /etc/passwd and /etc/group inside the
chroot filled with entries for root, mail and utmp for the base-files postinst
to work. Using mmdebstrap like that is indeed quite a hack right now, so I'm
not claiming that mmdebstrap should be the reason for base-files to change. But
maybe this is a useful way for you of how to see this problem happening for
yourself.
Thanks!
cheers, josch
signature.asc
Description: signature
