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

Re: Six Bullseye packages that should be Priority: optional



Simon, et al,

Thank you for your excellent feedback!

On Mon, 5 Jul 2021 at 10:40:28 +0100, Simon McVittie wrote:

> 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, 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.

No worries.  The last thing I want to do is to add stress
to the Release Team.

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

Very good.

> 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.

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

> The ftp.debian.org pseudo-package 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.)

Excellent.  Of course, I will wait for Release Team feedback
before doing so.

> > 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.

Agreed.

> 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.

bind9-host (standard) Depends: bind9-libs,
so bind9-libs would be pulled in anyway.

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

python3-reportbug (standard) Depends: ... Depends: libreadline8,
so libreadline8 is installed by default.

> > 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.

Yes, since "standard system utilities" are selected by default.

> 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.

Yes, since apt (required) Depends: libgcc-s1, libstdc++6 .

> > 6) override: mime-support:oldlibs/optional
> >   * Currently net/standard
> >   * Justification: Transitional 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.

Agreed.

Thank you again!
Dan
Urbana, Illinois


Reply to: