Re: Tasks policy
It occurs to me that what AJ's trying to do and its results can perhaps be
restated as follows (with apologies to AJ -- you have the best of
intentions):
* Move control of what packages a task includes out of the hands of the
creator of the task, and into the hands of people who have commits to
some cvs repository somewhere[1].
* Eliminate all usefulness of tasks except when manipulated by one
single special purpose tool (tasksel). (This includes making it
impossible to install a task and receive bugfix upgrades to it later.)
But the only real differences between this proposed system and the system
Bruce wrote hurredly over Xmas for hamm or so are:
* In this system, we have these useless task-* packages cluttering up tools
that cannot use them, while in Bruce's system, the tasks were hidden
out of the way.
* Maintainers of task packages do get to provide a description of the
task. In AJ's system, that's really all maintaining a task package means
-- you maintain a package description, and nothing more.
* In Bruce's system, the task selector self-destructed and was not
callable after install.
AJ asked for a concrete counterpropsal, and this is mine: If you really
want to do this, just go back to Bruce's system. Redo it so it's not so
blasted ugly and confusing, fix the self-destructive aspect, but use the
same idea. Which likely means just hardcoding the tasks and what
packages comprise them in tasksel, and when a task is selected, have apt
install all available packages that are in the task.
If we need a quick fix for the task problem in time for the freeze, this
is it. <sigh>
--
see shy jo
[1] The more I think about it, the more the reasons for this incense me.
All this talk of overrides files has the unstated assumption that we
cannot simply file bugs on packages, and get their maintainers to
add the appropriate Task: or Enhances: or whatever fields. This is a
horrid assumption, and it says bad things about either the state of
Debian or the assumptee.
Reply to: