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

[Jeremy Katz]

On Thu, 2006-06-15 at 18:08 -0400, Bill Nottingham wrote:
> If all of this is on the wiki as future plans, I apologize.

Some of it is in the write-up from Roozbeh, some is scattered across
yum-devel-list and some of it is already done ;-)

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

> 5) user
>   a) reviews and approves package list
> 6) pup
>   e) downloads packages
>   f) checks transaction
>   g) updates
> 
> 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".

> 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.  Also, if you're interactively
saying that you want an update to occur, you want to give progress.
Which is no fun either.

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

Jeremy