Subject: Package `priority' policy

From: [email-masked] (Ian Jackson)
Date: Tue, 4 Jun 96 02:59 BST

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.