On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote: > Johannes Schauer writes: > > My advice would also be to switch from debootstrap to mmdebstrap because the > > latter is able to create a chroot with only Essential:yes packages in it > > while > > debootstrap includes Priority:required packages as well. Alternatively, > > debootstrap could gain a variant only installing Essential:yes packages and > > their dependencies (why doesn't it have that already?). > > Debian doesn't support systems that don't have "required" packages > installed. So buildds should have them installed.
If these statements are based on the policy quote below, then I do not agree. I don't see why e2fsprogs would need to be installed on a chroot, as long as there's nothing depending on it, for example. > Policy states: > "Removing a required package may cause your system to become totally > broken and you may not even be able to use dpkg to put things back, so > only do so if you know what you are doing." That seems wrong, or inaccurate at best. dpkg should never depend on anything that is not part of the pseudo-essential set (strictly speaking only Essential:yes + awk-virtual), or that it depends on explicitly. So as long as a package has not been forced out, dpkg must work. Removing a required package (that is not Essential:yes) might indeed render your system broken, but what broken means or in what context is not qualified there. This could apply to systems that get booted for example, but not to chroots. A package that relies on another package that is Priority:required and not Essential:yes, and that it does not depend on, is just broken. Here's the current list of these packages on my system: $ aptitude -F '%p' search '~prequired !~E' debconf e2fsprogs gcc-10-base gcc-9-base libpam-modules libpam-modules-bin libpam-runtime mawk mount passwd tzdata And most of these are actually part of the pseudo-essential set anyway, and cannot be removed w/o force. That passage in policy might have made sense some time ago, when Priority:required almost matched the pseudo-essential set, and when we didn't have a separation of "dpkg-essential" and "boot-essential". Regards, Guillem
