[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required



Package: debian-policy
Version: 4.5.0.0
Severity: normal

Hi!

This was brought up on debian-devel, and I think it needs to be
updated/corrected in the policy manual:

On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote:
> 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


Reply to: