On Fri, 2006-06-16 at 14:28 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj(a)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