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

Tasks policy

(Cc'ed to debian-boot)

(First in porbably a series of policy changes needed for woody...)

So, here's the deal. We need to get a proper policy for tasks fairly soon.

tasksel in sid supports a "Task:" header for packages so we can be a
little more flexible than having every task- depend on everythig in it.
This was discussed on -devel just after potato released, I think consensus
was that we should use override files to populate these fields, rather
than letting maintainers add their own packages directly to tasks. I'm
not sure if we came to a consensus about how these override files would
be maintained though (or who by: ftpmaster? -boot? the individual task-*
maintainers?). It's probably best to put it in boot-floppies CVS, and have
dinstall use that.

The basic way tasks should work are (and I think there's a rough consensus
on this too):

	* There should only be a limited number of tasks

	* Each task should be useful to a large number of users (special
	  interests can use apt-get after install)

	* Tasks should be oriented on the goal; two tasks shouldn't do
	  effectively the same thing

	* Most packages in a task should be specified using the Task: header
	  so that (a) they can be removed without necessarily deselecting
	  the task, and (b) so that if they get removed before release, the
	  task- package doesn't get broken

	* task-* packages shouldn't suggest: or recommend: other packages,
	  nor depend on virtual packages or list alternative dependencies
	  (ie Depends: foo|bar|baz): dependency resolution isn't handled by
	  tasksel, and shouldn't be, so a non task-* meta package should be
	  used instead if such things are desirable. (Using the Task: field
	  probably obsoleted most of the use of recommends/depends in tasks)

	* task-* packages shouldn't conflict with each other, or with
	  required, important or standard packages (since such things
	  can't be resolved from within tasksel). If that sort of thing
	  is desired, a metapackage should be used.

	* tasks should be priority optional (and thus packages in
	  tasks should be priority optional),

Some further things which are probably desirable:

	* tasks shoudl have a section of their own
	  in dselect. "Section: dummy" or "Section: task" would seem
	  sensible to me

	* tasks should follow a naming convention so they can be organised
	  better by tasksel. Probably:

	* we should have tasks specifically for emacs and tetex (even though
	  both could be replaced by a wordprocessor in task-office, say).
	  and require any additional tasks like this get run through policy
	  first. If nothing else, historical reasons are a good argument
	  for tetex and emacs, and are obviously immune to slipper
	  slopes. :)

Note that this requires pretty thorough changes to our task- packages before
release. I think that's entirely desirable though, personally.

If people would like to indicate their willingness to second this, I'd be
happy to write up a proper patch.

If people want to disagree, I'd appreciate it if they'd be willing to put
in the effort to write a better proposal.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgpFVFWfumRy2.pgp
Description: PGP signature

Reply to: