(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