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

Bug#97755: [PROPOSAL] eliminating task packages; new task system

Package: debian-policy
Severity: wishlist


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[1] 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
recently discussed[2].

Tasksel will be modified[3] 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 @@
+        <sect1>
+	  <heading>Tasks</heading>
+	  <p>
+	    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
+	    installed.
+	  </p>
+	  <p>
+	    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.
+	  </p>
+         <p>
+           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.
+         </p>
+	  <p>
+	    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.
+	  </p>
+	</sect1>
 	  <heading>Maintainer scripts</heading>
@@ -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

[1] 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
[2] Perhaps most lucidly at the end of <20010512133943.B7471@kitenet.net>
[3] I'm starting work on that soon.

Reply to: