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

Re: Initial release of news (System V - like local news tool)



Carl V. Streeter writes ("Re: Initial release of news (System V - like local news tool)"):
> Ian Jackson writes:
> > Putting it in the base (ie, making it a Required package) is certainly
> > not appropriate - even Important wouldn't be, IMO.  Standard *might*
> > be but I'm unconvinced.
> 
> I'm thinking extra/misc myself, but I haven't thought enough about it to
> place it yet.  Especially since my thinking contradicts the maintainer's.

Here's the description that I wrote for Ian Murdock to describe what I
thought the various priority levels were for.  I think it's more or
less what has been put into practice.

This was originally part of a discussion with certain FSF people; I've
removed the bits that were only relevant to things they had been
saying.

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