puplet/pup/yum-updatesd... rethinking the mechanism

[Bill Nottingham]

Jeremy Katz (katzj at redhat.com) said: 
> > Looking at the update interaction as it currently stands:
> > 
> > 1) yum-updatesd
> > 2) puplet
> > 3) user
> >   a) clicks 'update'
> >   b) enters root password
> > 4) pup
> >   a) checks repositories
> >   b) churns metadata
> >   c) builds cache
> >   d) generates names of packages to be updated, including dependencies
> 
> Note that if you're within the time window of the check (likely), then
> the metadata update + check stuff doesn't actually have to happen as
> it's already been done.  That's one of the big reasons why yum-updatesd
> has to run as root -- this way, it can just update the existing metadata
> caches and we can just get the advantages of already having that done.

It seems to be happening every time for me. Probably some combination
of updatesd check timings + yum expiry timings. Might want to centrailize
these sorts of options.

> > Note that 4a-4d *completely* duplicates 1a-1d. This seems rather inefficient,
> > and leads me to wonder if a different model would be better.
> 
> ... except that the only thing that's really duplicated is "what are the
> updates of this set".

Still, why does it need computed again?

> > Consider an implementation where *all* the yum code lies in the updates
> > daemon; all puplet does is communicate over d-bus with it. The daemon
> > sends the list of packages, and then pup calls:
> >    
> >    setPackagesToUpdate(kernel, yum, glibc)
> >    updatePackages()
> 
> I don't want to have to do this securely.

How is this any less secure than giving pup root access?

> > The daemon can return a dependenciesNotSatisfied() error, or similar.
> > This leads to a faster experience for the user, as you're not duplicating
> > all the metadata reading & dependency handling steps in pup itself.
> > Moreover, you can make it seem even more seamless for the user by
> > having the option to opportunitstically cache updates in the background,
> > downloading them before the user actually asks to install them.
> 
> There's already the option to opportunistically cache updates.  And even
> to automatically apply them if that's your cup of tea. 

So now we have two means of auto-apply. :)

Bill