On Wed, May 09, 2001 at 04:57:13PM -0400, Joey Hess wrote:
> Attached to this message is a tarball which contains a rather simple
> program that uses debconf to present the user with a list of tasks
> (sorted into groups).
Are you serious?
No, really, are you?
I can't see any hint that you're not, but "newtasksel" seems to have
every flaw you were criticising my proposal for, and then some. So I'm
not really seeing where you're coming from.
It doesn't duplicate a number of features of the existing tasksel: 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. 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. Similarly, you can't look at
the tasks available from a release without installing software from that
release first.
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.
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. 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.
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 only reason I can conceive of that seems vaguely consistent for
rejecting tasksel 1.1 but not newtasksel seems to be that I wrote the
patch for it...
(Well, there's also that newtasksel has a categories, but that's not
too difficult to add to tasksel [0], and the tasks can be categorised
using the existing section overrides mechanism trivially)
Cheers,
aj
[0] Rough patch at
http://people.debian.org/~ajt/tasksel-sections.diff
--
Anthony Towns <aj@humbug.org.au> <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)
Attachment:
pgpX0CyC67c6a.pgp
Description: PGP signature