puplet/pup/yum-updatesd... rethinking the mechanism
Jeremy Katz
katzj at redhat.com
Fri Jun 16 18:54:32 UTC 2006
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
More information about the fedora-devel-list
mailing list