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

Re: New tasks status

On Fri, Oct 08, 1999 at 12:49:06PM +0200, Martin Bialasinski wrote:
> Matt> At this point, what is needed to bring things together and who is working
> Matt> on what?  I've only seen a brief discussion on creating a GUI (though
> Matt> there already is a workable one for the old profile/task scheme).  Maybe
> Matt> some further explanation of the end goals of this new scheme would help
> Matt> explain why we can't use the current GUI. 
> The reason is: I don't do sh.
> Therefore I want to create a new one in perl, using the same lib
> (Michael Dorman has created a deb; I have to make myself comfortable
> with it first). 

Do you mean using whiptail from perl?

> I would like to see
>    Server usage ->
>    Workstation usage ->

This isn't clear to me...are these options which reveal menus of tasks
specific to server or workstation functions on a separate page?

> [ ] some task
> [ ] some other

Also, is this just the menu structure you were thinking of once either
Server usage or Workstation usage was selected?
> where "server usage" would have tasks like the web/news/ etc. servers
> and similar for "workstation usage".
> You can go forth and back through it to select the tasks you want.
> I think this is already possible.
> New things:
> tasks can conflict (webserver-apache / webserver-roxen) this has to be 
> handled somehow.


> The extended description of a task has to be shown somehow. Either
> dselect like in a dynamic window, or kernelconfig like through a help
> button.  
> If you could add the things, the interface could be reused I think.
> BTW: the task-*.ctl files will be removed later, as they will be debs, 
> so better try to work with debs from the beginning. With a apt-cache
> | grep-dctrl pipe it is easy to extract the description and the name.
> You could fetch the tasks from Incoming and add a line to
> sources.list.

Right, I'm playing around a bit with a test task to get the feel of things
right now.   

I'm still unclear on whether the intention is to use the task packages as
packages or to simply browse the imformation in their control files using
apt-cache and friends from the GUI and then set-selection or install the
dependencies thay way.

One could still just "apt-get install task-admin" if they desired but would
not have the abilities to junk all the pieces from the same task if
desired.  I guess the task front-end should really handle this too, because
it would be awfully useful to be able to remove say task-sound and get rid
of all the cruft it install if you had no use for it at a later date.
Is there an existing tool/option that will attempt to remove as many
dependencies as possible when removing a package?

Matt Porter
This is Linux Country. On a quiet night, you can hear Windows reboot.

Reply to: