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

Re: Packages to install be default for Stretch



Ansgar Burchardt wrote:
> [ Please send replies only to boot@ ]
> 
> I would like to re-evaluate what we change by default for Stretch, that
> is the list of packages with priorities required, important and
> standard.  In general my plan involves installing less, taking into
> consideration that requirements and expectations what should be
> available in containers, chroots, on servers and desktop systems has
> changed (at least IMHO).

Thank you for working on this!  I'm interested in reducing the default
set of packages as well, and I've been filing bugs about reducing
priorities for a few releases now.

> Some ideas which might need further though:
> 
>  * I would really like to not list libraries at a priority greater than
>    optional. This tends to accumulate cruft, cf. #758234
> 
>    Examples from today's unstable: gcc-4.7-base, gcc-4.8-base,
>    gcc-4.9-base and gcc-5-base are at Priority: required.
>    libboost-iostreams1.5{4,5}.0 are at Priority: important
>    and so on.
> 
>    As far as I remember, debootstrap already ignores priorities for
>    library packages (Section: libs).

I agree; as the bug you link to indicates, this is a holdover from old Policy
that said a package must not depend on lower-priority packages.  As soon as we
drop that from Policy, we need to update priorities accordingly.  I agree that
we should not have any libraries or similar "only needed by dependencies"
packages in standard or above.

>  * It would be nice to have "init" demoted from required to
>    important: it is not needed in environments like (buildd) chroots.
>    This needs moving the essential bit to sysv-rc (which provides
>    invoke-rc.d and update-rc.d) and possibly other changes.

Please coordinate this with the systemd and sysvinit maintainers, since
we're also looking to reduce dependencies on packages like initscripts
and sysv-rc (so that they're not eventually not needed on systemd
systems).  If possible, it'd be nice to migrate to explicit dependencies
(direct or indirect) rather than Essential bits.

>  * I'm wondering if "tasksel(-data)" need to be "important"? I admit not
>    having used it outside of d-i. Is the installed version used as part
>    of the install process? Or could its priority be lowered to
>    "standard" or "optional"?

Given that task packages live in the Packages file these days, I don't think it
makes sense to put tasksel or tasksel-data in standard; let's drop them to
optional.  (Before that, there was some value in using tasksel to install tasks
after the initial install.)

>  * Same for question for "dmidecode": could the priority be lowered to
>    "standard"?

I'd personally drop it to "optional"; it's a handy tool, but not one
that needs to live in standard.  laptop-detect uses it, but
laptop-detect is optional, not standard.  And I personally don't see
much value in distinguishing laptops and desktops anymore; both want
good power management and connectivity these days.

> Some priority changes which I believe could be implemented:
> 
>  * Packages currently at "important":
>     - cron:
>       Not needed in chroot/container environments.
>       -> demote to "standard"

Agreed.  Personally I'd actually like to see it demoted to optional, but
that'll be harder.

>     - ifupdown, isc-dhcp-client, isc-dhcp-common:
>       Not needed in chroot/container environments. Might no longer be
>       needed on desktop systems (IIRC NetworkManager has a built-in DHCP
>       client in the last release, though not yet used by default).
>       -> demote to "standard"

network-manager has an explicit dependency on isc-dhcp-client, and when
it moves to its own DHCP client, that dependency will go away.  ifupdown
Recommends isc-dhcp-client but doesn't depend on it (because you might
have a static network).  Either way, those don't need to live in
important; standard suffices, with the added note that d-i needs to
install them if installing over a network that uses them.  One of these
days we'll get them pushed out to optional.

>     - groff-base, man-db, manpages:
>       Not needed in chroot/container environments or many server
>       environments.
>       -> demote to "standard"

Agreed.  standard is quite sufficient, though I don't think they should
be demoted outside of standard, since a normal install should end up
with them.  (In my very first install of Debian, on potato, I remember
spending a pile of quality time with manpages figuring out how to fix
LILO so I could boot back into Windows, and given that I had no network
connectivity...)

>     - less:
>       Not needed in chroot/container environments.
>       -> demote to "standard"

Agreed; for some reason I thought it already was.  Should definitely
stay in standard though.

>     - logrotate, rsyslog:
>       -> tempted to demote to "standard", but maybe only in buster

For logrotate, I'd actually argue for putting it in optional but keeping
it in the Recommends of rsyslog.  For rsyslog, I suspect it needs to
stick around in important, at least until we have an alternative package
that enables the systemd persistent journal and Provides:
system-log-daemon, at which point it can become optional.  *Some* kind
of logging should live in important.

>     - nfacct:
>       No idea why this is at Priority: important.
>       -> demote to "optional"

Yes please.

>     - netcat-traditional:
>       No IPv6 support...
>       -> demote to "standard", possibly to "optional" in buster

Or even "extra", since netcat-openbsd has many more features.

>     - traceroute, wget:
>       Useful for debugging, but not needed in chroot/container
>       environments.
>       -> demote to "standard"

wget is quite useful in chroots/containers, but I agree that both of
these can go down to standard.

>  * Packages currently at "standard":
>     - aptitude, aptitude-common:
>       There's already apt.
>       -> demote to "optional"

Agreed.  See thread on debian-devel; at this point aptitude is no longer
the "standard" apt frontend.

>     - at:
>       Rarely used (IMO).
>       -> demote to "optional"

Agreed completely.  People use it, but it doesn't need to exist in the
default install; it's just an "apt install at" away.

>     - bc, dc:
>       Rarely used (IMHO).
>       -> demote to "optional"

dc yes; you might get some pushback on bc, but personally I agree.

>     - dnsutils:
>       bind9-host provides a (limited) DNS query interface. No need to
>       install both bind9-host and dnsutils by default.
>       -> demote to "optional"

I'd actually argue for demoting bind9-host and keeping dnsutils, but I
certainly agree that one suffices.

>     - bsd-mailx, exim4*, procmail, mutt:
>       Often not useful on desktop systems, has popular alternatives,
>       probably not needed in chroot/container environments either.
>       -> demote to "optional"

I've been working on making the MTA optional for several releases,
slowly getting dependencies dropped or made optional (or packages
depending on an MTA moved out of standard).  At the moment, the last
holdout is that cron has no output logging without it.  I supplied a
patch fixing that, but these days I think the much simpler fix involves
just feeding the output to either logger or the journal.

mutt, procmail, and bsd-mailx are easy; we don't need a text-mode mail
client in standard, and we *especially* don't need a mail filtering
program like procmail in standard.  On top of that, mutt needs to stop
recommending mail-transport-agent, since it has native support for SMTP;
suggests suffices.

In doing this, you will run into a non-trivial number of people who will
complain that the way the vast majority of Linux desktop users set up
their mail clients is wrong, and that everyone should run their own mail
server and point MUAs at that rather than directly at an SMTP and
IMAP/POP server.

>     - ftp:
>       Brr, ftp.
>       -> demote to "optional"

Agreed.  It's just an apt away.

>     - info, texinfo, install-info:
>       I admit having used info only in desperation. Most documentation
>       comes in man page format.
>       -> demote to "optional"

texinfo absolutely; that's only used to *build* info pages, and it
should never have been standard.

info depends on install-info, so only info would need to be standard.

Personally, though, I sympathize with wanting info in standard, for the
same reason as man.  But only info, not texinfo.

>     - host:
>       Transitional package.
>       -> demote to "extra" (+ Section: oldlibs)

Or drop entirely in favor of the Provides of bind9-host.

>     - m4:
>       Rarely used (AFAIK). Well, at least outside of auto* and sendmail.
>       -> demote to "optional"

Agreed; anything that needs this can depend on it.

>     - mlocate:
>       Rarely used (AFAIK).
>       -> demote to "optional"

Agreed, and on top of that, it runs a daily cronjob.  Kick it to
optional.

>     - nfs-common, rpcbind:
>       NFS is not so common to include in every install. One less service
>       listening to the network.
>       -> demote to "optional"

Agreed.

>     - patch:
>       Does anyone use this w/o having build-essential installed?
>       -> demote to "optional"

I sympathize with wanting patch in standard (it's useful for more than
just building software, and diffutils is essential), but I also think
it's just an apt away, so yes, demote to optional.

>     - time:
>       'time' is a builtin in at least bash and zsh.
>       -> demote to "optional"

Agreed.  The additional data from /usr/bin/time (such as faults) helps
in some cases, but not enough to put it in standard.

>     - w3m:
>       I think text-mode browsers are not worth including in the default
>       install. It is *very* rare to not have another computer to use.
>       Plus in the worst case the package is still just an apt-get away.
>       -> demote to "optional"

Completely agreed.

>     - whois:
>       Too special to include in standard install.
>       -> demote to "optional"

It's a useful diagnostic tool, but not so useful that it needs to be
installed by default, true.

- Josh Triplett


Reply to: