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