Jeremy Katz (katzj@xxxxxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
