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

Re: Six Bullseye packages that should be Priority: optional



On Mon, 05 Jul 2021 at 02:30:00 -0500, Daniel Lewart wrote:
> Comparing important/required/standard packages between
> Buster and Bullseye, I noticed some inconsistencies.

We have been in hard freeze for almost 4 months[1], so I don't think
now is necessarily the right time to be changing what is in a default
installation of Debian (which is what the boundary between standard and
optional means) without release team approval.

I've cc'd the release team to see what they think.

I agree with your reasoning for why these packages should be
Priority: optional, and for any that cannot be changed in bullseye, the
beginning of the Debian 12 'bookworm' release cycle would be an excellent
time to make that change.

[1] https://release.debian.org/bullseye/freeze_policy.html

> If so, should I file one or multiple bugs against:

The ftp.debian.org pseudopackage is the right place to ask for priority
changes ("override changes"): individual packages' maintainers cannot
change this on their own. If you use reportbug, there's a template for
an override change.

It's probably best to Cc the package maintainer
(NAME_OF_PACKAGE@packages.debian.org) using the X-Debbugs-Cc mechanism,
because there is a suggested priority in the package's debian/control,
which the ftp team use as a basis for setting the priority of new packages.
(Yes, it's redundant, and there are probably better ways this could be
controlled, but this is what we have at the moment.)

> 1) override: bind9-dnsutils:net/optional
>   * Currently net/standard
>   * Justification: Buster dnsutils is net/optional

This is essentially asking: should the DNS utilities (dig, nslookup etc.)
be installed by default even if nothing else depends on them? and changing
the answer to that question seems a disruptive thing to be doing during
hard freeze.

These have relatively "heavy" dependencies, so they are probably the
highest-impact in terms of reducing the size of a default installation;
but they also seem like the highest-risk in terms of potentially exposing
bugs where packages rely on these utilities without declaring a dependency.

> 2) override: bind9-libs:libs/optional
> 5) override: libreadline8:libs/optional
>   * Justification: Debian Policy 2.5

I agree that shared libraries should be Priority: optional. They will be
pulled in by dependencies if they are needed.

bind9-libs is pulled in by bind9-dnsutils, so there is no point in changing
that priority unless bind9-dnsutils is also changed.

libreadline8 is quite small, so the impact of installing it unnecessarily
is low.

> 3) override: gcc-9-base:libs/optional
> 4) override: gcc-10-base:libs/optional
>   * Currently libs/required

These are not *really* shared libraries, but the same reasoning applies,
and I agree they should be Priority: optional.

If I'm reading correctly, gcc-9-base is included in default installations
of Debian 11, even though nothing else built by src:gcc-9 is, nicely
demonstrating why Policy §2.5 changed to its current contents. This seems
like it's obviously a bug (200K of licenses and documentation are installed
unnecessarily), and unlike the other genuine bugs you've mentioned here,
this one seems low-risk to fix, because gcc-9-base only contains
documentation.

In practice gcc-10-base will be installed anyway, as a result of libgcc-s1
depending on it, so that change would have no practical effect right now;
but moving it to Priority: optional would avoid having the same bug as for
gcc-9-base when we upgrade to gcc-11 or later in a future Debian release.

> 6) override: mime-support:oldlibs/optional
>   * Currently net/standard
>   * Justificatino: Transtional package

mime-support depends on mailcap (Priority: optional) and media-types
(Priority: standard), so downgrading mime-support to optional would mean
that mailcap (compose(1), edit(1), see(1), print(1)) would not be installed
by default. That seems like it has a risk of exposing bugs where packages
rely on those tools without declaring a dependency.

I agree that this should be oldlibs/optional, but 4 months into hard freeze
doesn't seem like the right time to change it.

    smcv


Reply to: