Re: Tasks policy
Anthony Towns wrote:
> Or moving them into the task package themselves, but not in the control
> record? Or shall we just forget I suggested that originally.
Well, I had.
That's a reasonable alternative. Oh, except, I seem to remember you wanted
to use some special-purpose field for it, when we again have perfectly
good general purpose fields, Suggests and Recommends, that already do the
same thing.
> > * 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.)
>
> Yeah, because hey, if the tools aren't written now (or at the very least
> mandated by policy) it'll be impossible to ever write them in future.
I think it very unlikely that we will ever get support for some hackish
field only used by task packages into Dselect, and Dpkg, and Apt, and
Aptitude, and Deity, and Red Carpet and ...
This is why I have been trying to generalize the thing all along. A more
general purpose field will be more generally used, and so people will
have more incentive to implement it. Plus, it probably solves some other
problems out side of task space.
> > 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.
>
> "Forget all the code that exists and is working right now, and rewrite it
> based on this old code that everyone's forgotten."
Bruce's stuff was not so bad. Aside from being a rushed implementation,
the idea was pretty good.
--
see shy jo, ignoring certian nuances
Reply to: