[Yum-devel] What to do about yum-updatesd?

[Jeremy Katz]

On Thu, 2007-07-19 at 17:09 -0400, James Antill wrote:
> On Thu, 2007-07-19 at 15:23 -0400, Jeremy Katz wrote:
> > After a couple days of just seeing if it's feasible, I've got something
> > now that looks like it works and fulfills most[1] of our more full list
> > of requirements[2].
> 
>  Cool, I wondered about going this route ... but wasn't sure what you're
> reaction would be.
>  One thing I had considered when I'd thought about it was having three
> stages:
> 
> 1. Long running C daemon.
> 2. python helper to get current list of updates.
> 3. python helper to install some/all of current updates.

The third one is the one that I'm not entirely sure I'm happy about how
it feels yet.  The nice thing is that we're in no way precluding it if
we become more comfortable with the idea in the future.

> ...mainly because this seemed like it would integrate better with the
> panel applet and it might make it easier to implement a couple of
> features.

It has some upsides, but it also makes some things significantly more
complicated.  Little things like progress bars are no longer quite as
obvious as they once were.

> >   To get it, you can currently do
> >   git clone http://katzj.fedorapeople.org/git/yum-updatesd.git
> > or grab the packages (epoch 1 so they upgrade what's in yum) from   
> >   http://katzj.fedorapeople.org/repos/yum-updatesd
> > 
> > Thoughts, comments, testing appreciated.
> 
> . It seems kind of ugly to have the daemon spawn a short lived helper
> and then get it's data back via. dbus.

Well, the idea is that things like puplet will move to the new async
method of getting update information.  At which point the daemon isn't
really responsible for "knowing" any of the information.  Getting the
information and caching it is really only useful as we can't keep
interface compatibility otherwise.

> . I think you want the top level gamin monitoring to add new directories
> to the watch list, no?

Probably.  Added

> . So, I might be wrong, but I don't see a call to invalidate_cache()
> after an update (emitUpdateApplied doesn't seem to do that in the daemon
> part). But maybe I'm just missing something here.

Well, it probably happens, but mostly by accident.  /var/lib/rpm will be
changing as packages are installed -- the last event from this will
probably be noticed after the helper has exited.  But added a more
explicit one just so we can be sure that it happens.

> > [1] The big thing missing is that the daemon side is still written in
> > python because that's faster to do.  The advantage of moving it to C
> > will be a lower memory footprint which is probably worth it for a system
> > daemon.  But that can also be a second step.
> 
>  If you don't want to do it, I can take a look at this bit as I've still
> written more C than python this year :).

If you want to, I definitely won't complain.  It's not like my
whiteboard is lacking of things that I'm in theory working on ;-)

Jeremy