On 8/9/06, Benjy Grogan <benjy.grogan@xxxxxxxxx> wrote:
Yep, it's Comical. Is this that rare of a situation that you can pinpoint the rpm? In this case I don't mind the repo switch if Extras no longer will hold Comical. But shouldn't there be a warning message that pops up when a repo switch occurs? It's not really a situation of prohibiting this behaviour with protectbase, or allowing it by default, but more or less being able to be aware that the rpm is being pulled from another repo. I was curious and discovered this in the details. Seems like a feature that would be worth putting into Pup, along with the standard 'do you want to see this warning in the future?'.
Which field in rpmdb on your system do you think makes the best guess as to which repo a currently installed version of a package is from? There is no header field that can garuntee to catch a repository change since the rpmdb does not record the url from which the package came. Vendor fields are not authorative, Packager fields are not authorative. Buildhost is not authorative. At best you can do a signature comparison to check to see if a package is signed by the same key as the update(which will I would expect noticable slow down the update process). Obviously this only works for signed packages, and even signature comparisons will not catch all repo by repo changes IF the same key is used to sign packages for multiple repos. It will catch a jump from extras to livna, but not something like a jump from Core to updates or updates to updates-testing, which i think are still all signed with the same key(s). Nor is key checking going to work for mongrel repos, which have packages built and signed from other locations in the same repository structure. There simply is no repository heritage information stored in the rpmdb about currently install packages which can be considered authorative for all possible situations. The closest thing is a signature change. And while I have illustrated that checking for a signature change isn't perfect I think such an optional check does have value. A change of signature with a package update is definitely something I would followup on before allowing an update if I were notified of that situation. But I'm far from a regular user, and I couldn't fathom whether or not this sort of 'red flag' would be beneficial to the 99.9% of the users closer to the median than I. For all I know this information would only be ignored as a nag dialog and summarily ignored. -jef"completely underwhelmed by the skeeters here"spaleta -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
