On Fri, 2006-06-16 at 14:28 -0400, Bill Nottingham wrote: > 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. 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
