Hi, for everybody else who is reading this bug and was not reading debian-devel at the same time, here is the thread that Tim started there for more context: https://lists.debian.org/alpine.DEB.2.20.2102211635290.6837@einstein.home.woodall.me.uk Quoting Tim Woodall (2021-02-22 18:28:56) > On Mon, 22 Feb 2021, Helmut Grohne wrote: > > On Mon, Feb 22, 2021 at 07:33:10AM +0000, Tim Woodall wrote: > >> A. /etc/passwd is part of base-passwd's interface and base-files is > >> right in relying on it working at all times. Then base-passwd is rc > >> buggy for violating a policy must. Fixing this violation is > >> technically impossible. > >> > >> > >> I seem to have hit this same issue independently. > >> > >> Could you explain why "Fixing this violation is technically impossible" > > > > The requirement here is that base-passwd needs to work when unpacked. > > The only way to make that work is making /etc/passwd a conffile. That > > would technically be possible, but it would be very annoying, because > > this file is different on virtually any Debian installation. So we > > cannot make it a conffile in practice. The next bet would be ensuring > > that base-passwd.postinst is run before other packages' postint somehow. > > Such an ordering mechanism does not exist at present and it would be > > prone to dependency loops. > > > >> As far as I can see, making base-passwd not essential, only required, > >> and then making passwd and base-files pre-depend on base-passwd the > >> system seems to bootstrap /etc/passed and /etc/group OK. > > > > What you write is almost certainly self-contradictory. base-files is > > essential. Anything it depends on (including base-passwd in your > > scenario) is pseudo-essential and thus inherits all the same > > requirements except for actually being essential. You gained nothing. > > And you didn't explain how you'd make base-passwd non-essential. > > > >> That also seems to conform to the debian policy. The oddity is that > >> base-files and passwd only actually need to depend on base-passwd, not > >> pre-depend on it as they only use /etc/passwd and /etc/group in the > >> postinst scripts but the debian policy doesn't seem to consider this > >> case. > > > > They don't have to depend on base-passwd at all, because dependencies on > > essential packages should be omitted. > > If base-passwd wasn't essential then passwd and base-files should depend > on it. > > If passwd and base-files (pre)depend on base-passwd then base-passwd > will be configured before passwd or base-files postinst is run. In your mails to debian-devel and to this bug you are mixing some orthogonal problems. Please note, that Debian policy does *not* describe how to create a Debian chroot from zero. Specifically it does not cover the situation in which a package was *never* configured. So when it says that packages in the Essential:yes set must work even without being configured, then this is talking about package upgrades where packages from the Essential:yes set can find themselves in the configure stage but still have to work. Yes, this should be clarified in Debian policy. Since Debian policy does *not* talk about the debootstrap scenario, you can *not* make the argument of "you have to add the Depends because Debian policy says so". Remember, that Debian policy documents existing practice, so if we want to at some point document the debootstrap scenario in Debian policy, we first have to make it work properly in the first place. For reasons that Colin and Helmut already listed, I don't think adding more dependencies between Essential:yes packages or dropping Essential:yes is the right way forward. If you start adding dependencies between packages in the Essential:yes set, depending on what they use, you will very quickly end up with a lot of circular dependencies and you are back at square one. As the author of one of the debootstrap programs (mmdebstrap) I would welcome you investing time in properly solving this problem. For this I suggest you open a bug against dpkg because I think it's there that this has to be solved. > > I suggest that you detail on the practical issue you have been hitting. > > Doing so allows evaluating prospective solutions against all relevant > > use cases. > > > > What I am doing - which seems similar to what others are doing with > other tools, is to: > > 1. unpack apt, dpkg and debian-archive-keyring data.tar.xz into tmpdir/ > (This provides a set of config that apt needs to run) > > 2. create a sources.list in tmpdir and touch image/var/lib/dpkg/status > (dpkg needs this file to exist) > > 3. apt-get install -o RootDir=tmpdir -d $ESSENTIAL > (This resolves all of the dependencies and downloads every package that > needs to be installed. I cannot see a way to get apt to do this without > jumping through the hoops of step 1 and 2 as --reinstall doesn't > re-download dependencies) > > 4. unpack the data.tar.xz from every deb downloaded in 3 into image/ > > 5. repeat step 2 but in image/ > > 6. chroot image/ > apt-get update > apt-get install $ESSENTIAL > > And expect that to create a fully configured system. > > For buster at least, the _only_ sticking point is apt not configuring > base-passwd early enough so one or the other of base-files and passwd > postinst fails. I've created local copies of those two that have > an explicit dependency on base-passwd and the problem is solved. > > I haven't tried with unstable or bullseye yet but I don't immediately > see any other issues. This is exactly what mmdebstrap does. I broke it down into a shell script and I guess what you do is something very similar: rootdir="$1" arch=$(dpkg --print-architecture) for d in /etc/apt/apt.conf.d /etc/apt/sources.list.d /etc/apt/preferences.d \ /var/cache/apt /var/lib/apt/lists/partial /var/lib/dpkg \ /etc/dpkg/dpkg.cfg.d /tmp; do mkdir -p "$rootdir/$d" done cat << END > "$rootdir/tmp/apt.conf" Apt::Architecture "$arch"; Apt::Architectures "$arch"; Dir "$rootdir"; Dir::Etc::Trusted "/etc/apt/trusted.gpg"; Dir::Etc::TrustedParts "/etc/apt/trusted.gpg.d"; END touch "$rootdir/var/lib/dpkg/status" echo "deb http://deb.debian.org/debian/ unstable main" > "$rootdir/etc/apt/sources.list" APT_CONFIG="$rootdir/tmp/apt.conf" apt-get update APT_CONFIG="$rootdir/tmp/apt.conf" apt-get --yes -oApt::Get::Download-Only=true dist-upgrade for f in "$rootdir"/var/cache/apt/archives/*.deb; do dpkg-deb --fsys-tarfile "$f" \ | tar -C "$rootdir" --keep-directory-symlink --extract --file - done export DEBIAN_FRONTEND=noninteractive export DEBCONF_NONINTERACTIVE_SEEN=true export PATH=/usr/sbin:/usr/bin:/sbin:/bin chroot "$rootdir" sh -c "dpkg --install --force-depends /var/cache/apt/archives/*.deb" Above shell script will succeed. Though from what you write above I guess your last line instead is using apt instead of dpkg: chroot "$rootdir" sh -c "apt-get install --yes /var/cache/apt/archives/*.deb" And then we get: Unpacking base-files (11) ... Setting up base-files (11) ... chown: invalid user: 'root:root' dpkg: error processing package base-files (--configure): installed base-files package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: base-files So a simple workaround for you might be to just use dpkg for the initial installation and then use apt later. So yes, workarounds are (sadly) still necessary to debootstrap Debian. But arguing with Debian policy is the wrong way forward as policy does not talk about the debootstrap scenario but only about the system where your packages were at least configured once before. To find a good solution that can make it into Debian policy, talk to the dpkg maintainers and write patches against dpkg. As the author of mmdebstrap I already got them to integrate several changes into dpkg that make the work for programs like debootstrap and mmdebstrap easier and with features like DPKG_ROOT I'm very confident that they will greatly appreciate your help in further improving the situation. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature