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

[Jeremy Katz]

On Fri, 2006-06-16 at 14:28 -0400, Bill Nottingham wrote:
> 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.

Agreed -- now that we're accessing the main yum.conf from yum-updatesd,
that'll be easy to fix up.

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

What if something has changed since the last time the daemon ran?  There
are cases which could end up installing/updating packages which you had
since done a removal around.  And in any case, as long as the interface
is doing the updating, you have to have done all the hard stuff around
finding "what are the updates"

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

It means we have to implement a whole new way of doing access control in
puplet instead of just relying on userhelper like everything else in the
distro. <Insert davidz pimping PolicyKit here>

> > > 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. :)

You mean the cron job?  Yeah, that's gonna die ;)

Jeremy