Some Pup/Pirut suggestions

[dragoran]

Jeremy Katz wrote:
> On Sat, 2006-06-17 at 09:01 +0200, dragoran wrote:
>   
>> 1)Make them somehow threaded...
>> The gui sometime does not respond or even redraw when some "huge work" 
>> is done in the background (even on a dual opteron box).Would spiltind 
>> the gui from the backend stuff into seperate thread help? the gui can be 
>> updated / rewdrawn while the other thread is doing the work.
>>     
>
> It could "help", but there's a significant cost in code complexity and
> difficulty in debugging things.  I'm not fully convinced that it's worth
> the cost especially as it becomes much less of an issue with a
> compositing manager running.  
>   
how would a cm help here?
> Really, it's better to try to get to where areas that take a long time
> actually have a way of providing feedback of progress -- if you can
> identify specific operations where things are taking a while and leading
> to the UI not refreshing, please file them as separate bugs and I can
> look into each case -- in most of them, I expect that there are ways to
> resolve them that don't involve the complexity of threads
>  
>   
ok this seems to happen when pup is downloading from a slow mirror; 
doing a ldconfig that takes long;
doing a restorecon after selinux-policy update etc.
will try to track them; provide more info an fill bugs.
>> 2)Why does pirut close itself after it has done a task? for pup its ok 
>> to be closed after it has completed updates but pirut? After installing 
>> an app sometime I want to delete an other one or install a second one. I 
>> know that I can select many tasks at once but I see no reason why pirut 
>> should close it self.
>>     
>
> There's a bug/rfe filed about this and I'm planning to get to it in the
> FC6 cycle... just needed to get test1 out first.
>   
ok good news; what about cd/dvd support? wasn't this planned as a fc5 
update? (at least the wiki says so)
>   
>> 3)Pup should show more info on updates like description a "normal" user 
>> may get confused by just seeing a name like hal, dbus or libXX. If pup 
>> could somehow show a description of what this package are this would be 
>> solved.
>>     
>
> Work is underway to make all of the update information available to pup
> (and even just yum) so that you can see what the purpose of the update
> is, the severity, etc. 
>   
ok
> Jeremy
>
>