rawhide report: 20070725 changes

[Jeremy Katz]

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.

> -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

> -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

Jeremy