[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tasks: counterproposal (and implimentation)



Anthony Towns wrote:
> you can't see the packages that comprise a task or their descriptions, nor
> can you include a long description. ie, the whole "Task Info" thing's
> missing.

I don't think that's very important. A task is supposed to satisfy a
simple, well-defined need. If you want a web server, you shouldn't care
much which one.

Also, this is one of the reasons I think we should give people the
opportunity to drop into dselect/something better after broadly
outlining their tasks to they can tweak the result if necessary.

I think we should do that no matter what system we eventually decide
upon for defining and presenting tasks.

> It also doesn't support third parties who might want to use
> tasks: you can't just add an extra line to your sources.list and get a
> "Ximian Desktop" made available, for example.

True enough. I used to work at a company that internally used special debian
tasks, so I suppose I should have thought of that.

I'll think about it, but this may well be a fatal flaw in my proposal,
if we consider this an important need to meet with tasks.

> Similarly, you can't look at
> the tasks available from a release without installing software from that
> release first.

I don't really understand the importance of that.

> If you ever add apt-get support, btw, you'll need to be careful to avoid
> duplicating the existing task bug, ie if any package in a task goes
> missing an "apt-get install foo bar baz" (which is what tasksel does)
> will fail.

Note that the way base-config runs tasksel avoids that: use dpkg
--set-selections and if something is not available, dpkg ignores it.

> There's also the possibility that an entire task will need to be made
> unavailable, either because every package (or every significant package)
> included in it is buggy, or in postgresql/task-database's case, because
> might only be available from non-US.

I actually have been thinking since I posted the code about some
enhancements to deal with cases where all the packages in a task, or at
least some of the important ones, are missing. Noticing all are missing
and not displaying the task in the list is easy enough. Noticing that
the core packages of a task (postgresl, apache) are missing and deciding
not to show the task is also doable, it really just requires one list of
the key packages that mist be present, and another list of ancillary packages
that can go missing w/o badly breaking the task.

> This ought to be able to be done
> without modifying newtasksel, since, according to the freeze plans,
> newtasksel will be frozen (as part of the base system) while the tasks
> and their packages (as part of the "standard" system) are still be fixed
> or removed.

Split out the task data and move it to a standard priority package then.

> And all the things you and others have already complained about are
> also applicable to newtasksel: no support for people who want to just
> install a task from the command line, tasks not being handled by dselect
> or apt-get or deity (and at this point, I'd have to say not ever being
> able to be handled, whatever the authors of those programs might want).
> 
> Basically, if you're satisfied with "newtasksel", I'm not really sure
> why you'd object to tasksel 1.1. But if you didn't object to tasksel 1.1,
> then you wouldn't've written newtasksel in the first place...

The core to all of those objections about tasksel was that tasks were
debian packages. So we *expected* to be able to use them just like
regular debian packages. We wanted to be able to use them with apt, with
dselect, and so on.

If tasks are no longer enbodied by rather strange debian packages, all
these expectations go away. They're something different, and you
interact with them differently. That's the whole point of my proposal,
really. If people don't understand that, I don't think I can explain it
to them any better than I already have, and perhaps I should just give
up and add another item to my
list-of-things-I-really-wish-debian-did-differently-but-will-never-be-fixed.

(BTW, could someone from Progeny PLEASE speak up and give us a summary
of how your task analog works?)

-- 
see shy jo, wondering about that German blood



Reply to: