Bug#97755: [PROPOSAL] eliminating task packages; new task system
After a lot of discussion, AJ and I have settled on a compromise that is
acceptable to both of us about what to do to fix Debian's broken task
Essentially, we propose throwing out all existing task packages, no
longer using packages at all to deliver task information, formalizing
the process by which tasks are modified/added, and moving the information
about what packages belong in each task out to the packages themselves
(or to the Packages file).
The new system:
Rather than having task packages any more, individual packages that
belong to a task can have a Task: control file field that lists the
names of tasks they are a part of. This field can also be added to the
Packages file by way of an override, even if a package does not contain
it. Doing things this way has a lot of benefits that AJ has recently
That is half of the data tasksel needs to display a task. The other half
is a description of the task (and ancillay information like the name of
the task, a section it is in, etc). That information will be delivered to
tasksel in the form of a single file (format much like a debian/control
file) which will ship with tasksel or in another package. We have
decided not to use individual debian packages for reasons which I have
Tasksel will be modified to put these two sources of information
together and display tasks for selection much as it does now.
To roll this out in time for woody's freeze, we will make heavy use of
the overrides to add Task: fields to the Packages files. The possibility
is left open that later the overrides might be done away with, or
packages will at least be able to include matching Task: fields, but we're
not going to do that for woody, since there isn't time.
To make this happen in time for woody, I want to form a task force of 3
to 5 people to, in the next 3 weeks, look at the existing task packages,
and decide on a list of tasks that should come with woody, and come up with
the lists of packages that go in the tasks. This is intended as a
bootstrapping effort, not a group that will have long term control over
the tasks. If you're interested in being on the task force, please mail me.
Here's the actual proposal. I am of course looking for seconds.
--- policy.sgml.orig Tue May 15 21:57:25 2001
+++ policy.sgml Tue May 15 22:14:28 2001
@@ -1024,6 +1024,38 @@
+ The Debian install process allows the user to choose from
+ a number of common tasks which a Debian system can be used to
+ perform. Selecting a task with <prgn>tasksel</prgn> causes
+ a set of packages that are useful in performing that task to be
+ This set of packages is all available packages which have the
+ name of the selected task in the <tt>Task<tt> field of their
+ control file. The format of this field is a list of tasks,
+ separated by commas.
+ You should not tag any packages as belonging to a task before
+ this has been discussed on the `debian-devel' mailing list and
+ a consensus about doing that has been reached.
+ For third parties (and historical reasons), tasksel also
+ supports constructing tasks based on `task packages'. These are
+ packages whose names begin with `task-'. Task packages should
+ not be included in the Debian archive.
@@ -1282,8 +1309,8 @@
Having a separate package allows one to install
the build-essential packages on a machine, as
- well as allowing other packages such as task
- packages to require installation of the
+ well as allowing other packages and tasks
+ to require installation of the
build-essential packages using the depends
(AJ, note that I have changed it a bit from what you saw.)
see shy jo
 For the many reasons why we consider it broken and why it cannot be
fixed in its current form, see discussions on debian-boot, debian-policy,
and debian-devel in the past half year or so. Or just run tasksel
 Perhaps most lucidly at the end of <20010512133943.B7471@kitenet.net>
 I'm starting work on that soon.