rawhide report: 20070725 changes

[Hans de Goede]

Jeremy Katz wrote:
> On Wed, 2007-07-25 at 16:31 +0200, Hans de Goede wrote:
>> Jeremy Katz wrote:
>>> On Wed, 2007-07-25 at 03:33 -0400, Build System wrote:
>>>> New package yum-updatesd
>>>> 	Update notification daemon
>>> FYI -- this is a new and reworked yum-updatesd that should hopefully
>>> help with some of the complaints that I have been had.  The *big* change
>>> is that it's bit split into two pieces:
>>> * The actual daemon.  This is small, listens to dbus, and doesn't ever
>>> touch the rpmdb, etc.  Which should keep its memory footprint low.
>>> * Helper process that's forked off to do actual update checks
>>> (+downloads +installs if so configured).  Helper isn't threaded, which
>>> should avoid some of the problems that have been cropping up.
>>>
>>> People prodding and testing at this would be much appreciated; I'm
>>> hoping to be able to push this to F7-updates at some point as well.
>>> Bugs to bugzilla as usual
>>>
>> Does this also fix the issue where issuing any yum command wil fail while it is 
>> checking for updates? That is the no 1 reason for not to use yum-updatesd.
> 
> While the actual update check is going on, yes, things won't work.  But
> that's just like if you run a yum command while another one is running.
> The plus side is the thing holding the lock is a separate process that
> dies and shouldn't just get hung up in thread-land
> 
>> If it doesn't fix this, maybe the following is an idea:
>> -modify yum to detect if its yum-updatesd which is locking the current yum
>>   "database"
> 
> We could print out what the process holding the lock is easily enough I
> guess if people think it would be a substantial help.
> 

It would be a start, but see below.

>> -if it is yum-updatesd send it a signal to stop doing whats its doing, on which
>>   it will finish its current operation, and then release the db.
> 
> Can't really do this -- you can't just interrupt the metadata download
> or package installation, etc.  But the time period for which it should
> have the lock held should be able to be much more constrained now and if
> it gets stuck, should be far more debuggable
> 

With installation I agree, but yum-updatesd installing packages is not the 
default. And the meta datadownload needs to be done one way or the other, so 
the time lost while waiting for updatesd todo this is later won again.

>> -print: "waiting for yum-updatesdb to release the database"
>> -poll the database lock 2 times a second or so
>> -continue
> 
> This could also be done, but I'm not convinced that it's better than
> just dropping you back to a prompt.  The difference is
>   # yum update
>     ...
>     Lock is held by yum-updatesd-helper.  Spinning until released.  Hit
>     ctrl-c to exit.
>     ...
>     ...
>     ...
>     Got it, carrying on
> 
> vs
> 
>   # yum update
>     Lock is held by yum-updatesd-helper.
>   # (wait here, do other tasks, etc)
>   # yum update
> 

There are 3 important differences:

1. Despite recent cleanups yum still isn't exactly instant, so usually I type 
"yum -y foo bar" and then switch away, only to find yum-updatesd was holding 
the lock when I look to see if yum is finished

2. There is no way to tell when yum-updatesd is finished so one still needs 
todo the polling manual, very anyoing. Or as I do just kill it and disable it 
in ntsysv (which AFAIK is not what we want).

3. I give various Linux labs, where students often need to install package 
foobar, because I try to make my labs excercises as real life as possible 
(debugging bugs in bugzilla for example) and thus not all needed packages are 
installed in advance. To you and me the difference is as you describe above, to 
them however its the difference between yum working as expect and remarks along 
the lines like: "Hans it isn't working" or "WTF does this error mean?", so to 
regular end users the difference is huge.

Regards,

Hans