Package `priority' policy
Below is a somewhat-edited version of a mail message I sent some time
ago when our current priority scheme was developed; it summarises the
decisions that were made then.
Please read the list of overrides file additions in conjunction with
these definitions. Feel free to debate (briefly!) the priorities
assigned to packages, but because this is obviously a contentious
matter I intend to keep the decision-making process brief and not let
things get out of hand. If there's some kind of dispute we can refer
it to Bruce, but I hope that won't be necessary.
The problem with missing Section fields in Packages files is due to
the missing overrides file entries. I'm aware of the problem -
indeed, the daily cron job is telling me about it - and it will be
fixed.
Ian.
PS: Please CC all correspondence on package classification to
ijackson@chiark, as that's where I'm dealing with this issue and I
don't read debian-devel there.
------- start of forwarded message (RFC 934 encapsulation) -------
Subject: Re: classifications
[...]
Here is my list as it was agreed on:
Old category Meaning Abbrev Name
Base Absolutely essential. Req Required
Standard `Standard on Unix'. Imp Important
Recommended-A `Standard on Linux'. Std Standard
Recommended-B Useful stuff: X11, TeX, ... Opt Optional
Optional All the rest. Xtr Extra
Let me expand on those a bit:
* Required. You absolutely must not remove this or your system will
become unuseable and you will not even be able to use dpkg to put
things back. Systems with only the Required packages are probably
unuseable, but they do have enough functionality to install more
software.
* Important. 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 go `What the
F*!@<+ is going on, where is <foo>', it should be in Important.
This is an important criterion because we are trying to produce,
amongst other things, a free Unix. Other packages which the system
will not run well or be useable without will be here. This does
*NOT* include Emacs or X11 or TeX or any other large applications.
We're talking about the bare minimum infrastructure here.
* Standard. A reasonably small but not too limited character-mode
system. This is what will install by default if they don't select
anything else. It doesn't include many large applications, but it
does include Emacs (this is more of a piece of infrastructure than
an application) and a reasonable subset of TeX and LaTeX (if this
turns out to be possible without X).
* Optional. In a sense everything is optional that isn't required,
but that's not a helpful way to think about it. Optional is all the
stuff that you might reasonably want to install if you didn't know
what it was or don't have specialised requirements. This is a much
larger system and includes X11, a full TeX distribution, and lots
of applications.
* Extra. Packages that conflict with others with higher priorities,
or are only likely to be useful if you already know what they are or
have specialised requirements.
To think about it in terms of burden of proof:
- - In order to get something into Required you have to show that even
the most minimal system is broken without it and can't recoover.
- - In order to get something into Important it should be something that
has been on almost all versions of Unix (that means that Unix
programs' install scripts could use it) or is mandated in POSIX or
something, or that the system wouldn't really be useable or function
properly without.
- - In order to get something into Extra it has to conflict with
existing packages, or be very obscure, or very large, or be useable
only in very specialised circumstances or for specialised
applications, or have very complicated configuration requirements.
Preferably several of those reasons would apply.
- - That leaves us with the decision between Standard and Optional.
Standard packages make up a reasonable if somewhat small system. They
should usually not be very large, and shouldn't depend on X. Large
applications, especially, should not go in Standard. The user has a
tradeoff between functionality and disk usage, and we let them tune
this as follows: user should select only the Standard packages if they
want to optimise for disk usage, and select the Optional packages too
if they want to optimise for functionality. Alternatively they can
fine tune individual details.
[...]
Ian.
Reply to: