Re: Tasks policy
Anthony Towns wrote:
> So, here's the deal. We need to get a proper policy for tasks fairly soon.
Amen.
> 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.
I don't recall a discussion of or decision on using overrides files.
While it seems that letting developers create task packages willy-nilly
with no rules or supervision has been a disaster, the overall quality of
the dependnaices in individual tasks is ok, so I see no need to have
centralized control over that. Bug reports suffice. So no need for overrides
files.
I also don't understand why this new Task: header is being introduced. I
mean, I understand why you don't want to use dependancies. But why not
let tasks use Recommends and Suggests in a sensible fashion, and simply
make tasksel install all packages listed in either field by a task package?
This would make tasks usable in eg, dselect and any other decent apt
frontend, and it wouldn't add a new, seemingly hackish field.
> * tasks should be priority optional (and thus packages in
> tasks should be priority optional),
I think you mean the packages in a task should be option or higher (not
extra), right?
> * 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,...}
Well we could let tasksel use the Section field, or some new field instead
of re-overloading the package name. I think all those names are very, very
ugly. Wouldn't this be nicer --
Package: task-desktop
Tasksel-Section: user
Package: task-web-server
Tasksel-Section: servers
Or even (why overload package the field at all) --
Package: desktop
Task: yes
Tasksel-Section: user
Package: web-server
Task: yes
Tasksel-Section: servers
Or even this (the only problem with it is that our current set of
sections is so limited and hard to change) --
Package: desktop
Task: yes
Section: user
Package: web-server
Task: yes
Section: servers
> * 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. :)
It's worth noting that for a good 3 or 4 months after potato's release,
new installs that used tasksel did not get emacs or tex, or anything
else in standard, and that although people eventually complained about
other packages in standard not being installed, I never saw a single
complaint that those two were missing. After all, it didn't affect
upgrades, and I guess people who wanted emacs had no problem with using
apt afterwards.
--
see shy jo
Reply to: