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

[Bill Nottingham]

If all of this is on the wiki as future plans, I apologize.

Looking at the update interaction as it currently stands:

1) yum-updatesd
  a) periodically checks repositories
  b) churns metadata
  c) builds cache
  d) generates names of packages to be updated, including dependencies
  e) notifies puplet
2) puplet
  a) puts up notification with number of updates
  b) shows update information (if it exists)
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
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.

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()

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.

Opinions? Flames? Comments?

Bill