Re: Prevent packages from switching from repo to repo
On 8/9/06, Benjy Grogan <benjy.grogan(a)gmail.com> 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