(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:
task-devel-{c,c++,objc,haskell,...}
task-lang-{german,french,japanese,chinese,...}
task-server-{web,news,mail,database,dns,...}
task-user-{desktop,office,games,junior,...}
task-hware-{dialup,printer,laptop,...}
* we should have tasks specifically for emacs and tetex (even though
both could be replaced by a wordprocessor in task-office, say).
possibly:
task-sware-{tetex,emacs}
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.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <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)
pgp4xWMmjhKOs.pgp
Description: PGP signature
