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

Re: Priority dependence

On Sun, 18 Jul 2010 15:16:49 -0700
Russ Allbery <rra@debian.org> wrote:

apologies for this one being so long...

> Neil Williams <codehelp@debian.org> writes:
> > It is very worthwhile having a clear division between Required and
> > Important. A typical bootstrap should include Required but there is
> > no need for any of the important packages and any which may be
> > useful can be added explicitly.
> That's probably part of what I'm missing; what's the purpose of
> required in addition to essential plus dependencies?

Required provides a general-case base for many situations but even this
is too large a collection for some purposes. Required is a largely
complete set, it is hard to bring in more than about 30% of the
Required packages without bringing in the rest. Exceptions are probably
gcc-x.x-base, bash and dash or dash and bash, debconf (because cdebconf
should be possible instead) and e2fs* for SSD systems where ext* is a
waste of time.

Important adds nothing useful to that set - read as a *set* - although
it does contain *individual* packages that are useful to cherry-pick,
principally apt. 

A quick test gives Important as:

adduser  apt-utils  apt  aptitude  bsdmainutils  libbz2-1.0  cpio
cron  libcwidget3  debian-archive-keyring  dmidecode  libgdbm3  gnupg
gpgv  groff-base  ifupdown  iproute  iptables  iputils-ping
dhcp3-client  dhcp3-common  isc-dhcp-client  isc-dhcp-common
logrotate  libept1  libsigc++-2.0-0c2a  libtasn1-3  libusb-0.1-4
man-db  manpages  module-init-tools  nano  libncursesw5  net-tools
netbase  netcat-traditional  libnewt0.52  whiptail  libssl0.9.8
libpopt0  procps  libreadline5  libreadline6  readline-common  rsyslog
libslang2  tasksel-data  tasksel  libwrap0  info  install-info
traceroute  udev  vim-common  vim-tiny  wget  libxapian15

Of those, aptitude and it's dependencies are not necessary (just nice
to have sometimes), tasksel and dependencies should only be included
when using D-I, whiptail and readline (and dependencies) are not always
necessary, particularly when debconf is preset to non-interactive
(like chroots) and having both vim and nano is just overkill. I like vim
but even vim-tiny is not as small as it's name would indicate and yet
not sufficiently useful, compared to vim-full, to be retained on many

> Policy defines required as:
>     Packages which are necessary for the proper functioning of the
> system (usually, this means that dpkg functionality depends on these
>     packages). 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. Systems
> with only the required packages are probably unusable, but they do
> have enough functionality to allow the sysadmin to boot and install
> more software.

The only Important package which can be shoe-horned into such a
description is apt.

Required is reasonably OK at the moment, IMHO; the few packages that
are unwanted are not that large. Important is just too large a set and
contains packages that are simply not that "important" to everyone.

On a strict reading of the above, I would regard only those packages
utterly intrinsic to the unpacking of .deb files as Required - tar, ar,
and coreutils (or a modified busybox). (Yes, I have got into a situation
where a bootable system had no dpkg, no coreutils, no tar and no ar -
just a busybox shell - the unmodified busybox from DI. That led to a
reinstall. *That* is what I'd consider "totally broken".) ;-)

As a case in point, I think Policy 2.5 has this bit wrong:

"Systems with only the required packages are probably unusable, but they
do have enough functionality to allow the sysadmin to boot and install
more software."

Systems with only the required packages installed can be fully usable -
depending on the type of tasks expected of that system. The installed
packages still include enough functionality to allow the sysadmin to
boot and install more software.

I might even file a bug report against debian-policy for that one. It's
a subtle change but one that reflects the move towards making Debian a
truly Universal OS, not just a desktop and server OS (which, IMHO, it
was until, probably, Lenny).

> This sounds quite a bit like the definition of essential, except that
> required adds "allow the sysadmin to boot" and essential has the
> special unconfigured requirement.

.... yet no kernel package is Priority: required - nor should one be,
even though it's not that common to boot a runtime system without a
local kernel. 

> Hm.  So are there packages that aren't usable until configured but
> which should never be removed from the system?  I guess that would be
> the difference between required and the essential closure.

Even dpkg can be removed from the system if the admin is sufficiently
careful and uses a static configuration. (See Emdebian Baked [0])

These divisions are arbitrary and have been traditionally decided on
the basis of our own desktop and probably server configurations. There
are a lot more permutations now and the old dividing lines are only
shades of grey IMHO.
> > Please don't merge Important or lose the distinction between
> > Required and Important - Required is sufficiently bloated already
> > without adding Important. Far preferable (from an embedded
> > perspective) to drop Important and make everything else into a
> > default Priority (optional).
> Well, I was asking a question about the goals of the priority levels
> in the abstract, not about what's currently classified there. 

The goals need to be redefined because the *understanding* of the
current goals appears predicated on a desktop or heavyweight server
implementation when Debian is increasingly being used in much more
targeted ways.

Even if such devices are gaining more file system space, that space
should be restricted to user and application support data, *not*
unnecessary OS components.

Debian still has some way to go to being sufficiently slim to meet the
expectation of a "Universal OS" because a truly universal OS will
never get in the way of user requirements - and that includes not
taking up available space with packages that perform no useful
function on that specific type of device.

> If we
> merged required and important, obviously there's probably a lot of
> stuff that's currently in important that should drop back a level to
> standard.

Yes. Aptitude for one - and all it's dependencies, along with vim-tiny.
Although, see later, I think Priority: standard can go to /dev/null
> >> * Base installation.  The smallest possible installation you can
> >> put on a regular system and have a working and usable text-mode
> >> computer on which you can install other things and which looks
> >> like UNIX.  This seems to be what Priority: important is supposed
> >> to give you.
> > I disagree, Priority: required is all that is necessary for that
> > purpose.
> You disagree that's what Priority: important is supposed to give you?

Indeed. i.e. the packages currently specified as Priority: important
are not "the smallest possible installation" - that set is Priority:
required (and even that can be further trimmed), as outlined above.

I think that the Base installation is what Priority: required is
supposed to give us, albeit with apt added to Priority: required.
(However, if you use apt to install all Priority: required packages,
you always end up with apt installing itself anyway, so that point is

>     Important programs, including those which one would expect to
> find on any Unix-like system. If the expectation is that an
> experienced Unix person who found it missing would say "What on earth
> is going on, where is foo?", it must be an important package. Other
> packages without which the system will not run well or be usable must
> also have priority important. This does not include Emacs, the X
> Window System, TeX or any other large applications. The important
> packages are just a bare minimum of commonly-expected and necessary
> tools.
> That sure sounds like what it says.  Or do you think our
> implementation of important is buggy? 

Yes, our implementation is buggy because it appears predicated on
desktop and server implementations only.

> You're coming across as
> disagreeing vehemently with me but being insufficiently clear for me
> to be able to figure out what you're actually disagreeing with.  :)

There is nothing there about Priority important being a complete set but
merely a range of packages which have some common ground.

I'm disagreeing that the current list of packages deemed Priority:
important all fit the above description - mainly because the meaning of
the terms is vague and open to a lot of interpretation. "not be able to
run well" - as what? desktop? server? router? kiosk? netbook? NAS?

We cannot deal with a mythical person asking the "What is going
on?" question if that person expects a desktop system from a NAS. The
answer needs to be dependent on the kind of system - not all Debian
systems can or should be the same. The current Priority groupings are
too fat because our terms are too biased towards traditional Debian
target systems.

> There's an open Policy bug requesting clarification of the difference
> between important and standard, and I admit I'm rather fuzzy on that
> myself.

I haven't delved into standard - the fact that python is "standard" is
sufficient for me to not regard "standard" as anything of the sort and
to treat "standard" == "optional". I mean, why is every "standard"
Debian box meant to be an MTA and include both ftp and telnet clients
as well as debian-faq and wamerican? Do we want exim4 on an OpenMoko
phone or SLUG NAS?

To me, the whole Priority: field is outdated and almost completely
irrelevant to a large number of situations where Debian is commonly
used. I agree that Priority: required is mostly OK (with above
exceptions), but all other values I simply ignore when preparing
both Debian systems and programs that create Debian systems.

Yes, we need something like Priority: required and, on the whole, the
current list of packages in that set isn't too far off IMHO. As for the
rest, everything is optional in my book. i.e. Priority: could become a
boolean field - it is either required or optional, any other value
being handled as optional.

[0] http://www.emdebian.org/baked/


Neil Williams

Attachment: pgpRL98YYwYn1.pgp
Description: PGP signature

Reply to: