Re: cleaning up our task packages
(Sorry for overquoting, but I really need it to make a (fat) point).
On Wed, Dec 06, 2000 at 11:55:34PM -0600, An Thi-Nguyen Le wrote:
> [Ben Collins - Wed, 6 Dec 2000 11:46:01 PM CST]
> > Maybe we need a way to define subtasks so we get output like:
> >
> > [ ] LDAP : LDAP libraries, server and clients
> > [ ] LDAP Devel : LDAP Development libraries
> > [ ] LDAP Server : LDAP Server
> > [ ] LDAP Tools : LDAP Utilities
> > [ ] LDAP Name Service : LDAP NSS and PAM for Name Service
> >
> > Makes much more sense. Tasksel could unfold only when asked to do so, like
> > when a user is really interested in the tasks specifics, or they want only
> > certian portions of a task.
>
> How about just merge the many little but related tasks into a big
> task? Like task-desktop-environment, for instance, would still
> just be task-desktop-environment, but before downloading it would
> dig up little questions to ask you about the ones you selected, like
> so:
>
> TASK-DESKTOP-ENVIRONMENT
>
> Which desktop environments do you want to install?
>
> [ ] GNOME
> [ ] KDE
> [ ] XFCE
It is good idea to have that question asked, but I feel it is not the
best place to ask. I think this complexity should go into tasksel or
dselect. Combine that with what Ben says, and you get two types of
hierarchy relations in the tasks tree, going down to the level of detail
of distinct packages:
[*] Desktop Environment
-- Note that ( ) is not strict radiobutton, it just notes that
options are different alternatives for one thing
(*) Gnome
-- Gnome Core is selected implicitly
[ ] Gnome Dev
[ ] Gnome Office
[ ] Gnome Applets
[ ] Monitors
[ ] Clocks
( ) Clock and Mailcheck
(*) Afterstep Clock
[ ] Utility
[*] Gnome Games
[ ] Gnome Chess
[ ] Gnome Mines
[ ] Gnome xBill
[ ] Gnome Multimedia
( ) KDE
( ) XFCE
What's good about such hierarchical relations is that user is presented
with small number of options at once (user interface wisdom says that
human cannot hold more that 7 objects in mind, hence it is optimal to
present him with 6 and less interface options), while she is still able
to go into greater detail if she feels so inclined.
> This would also allow for more complicated questions on the installation
> of a task package. We can only stack so much information about all the
> task packages together on one page after all.
> > Of course, this requires the tasksel author agreeing to implement
> > something like this :)
>
> I don't know how much tasksel would have to change to do this one. :-)
This is what's bad: I see a lot of work should be done to make it cool
as this. Ever worse, if we can go in such great detail here, we should
not need dselect anymore, and it means that we better keep dselect
functionality here (depend/conflict resolution and package searching
come to mind).
Another issue is where the information making up task/package tree
should be stored. You can write it into control files like:
Package: task-desktop
Depends: task-gnome | task-kde | task-xfce, menu
and (not so pretty)
Package: task-gnome
Suggests: task-gnome-dev, task-gnome-office, ...
but you will run out of evil kludges as soon as you will have to make
gnome-glines appear as "Gnome Lines" in menu while short Description of
this package states "This is a version of the color lines program".
Better ideas, please?
Reply to: