On 5/1/07, Rex Dieter <rdieter@xxxxxxxxxxxx> wrote:
That doesn't fly with me. Compare that with the repotag-less situation of each repo providing packages with *identical* EVR's. Which is worse?
Once you have multiple vendors in the mix, each providing packages which may install over a package from another vendor there's no one-size fits all version comparison scheme which will hold. So to answer the question which is worse.. they are both significantly bad enough that your screwed either way. The only way to really solve the problem is to hold vendor as a separate metric by which to test against in a different way than version comparison. Vendor-ness simply doesn't translate to ordering in a programmatic way. Instead, you hold vendor-ness a parallel collection of namespaces in which you do version comparisons internally. So if I have package foo installed from the Vendor called babyeater, and updates for package foo are available from both the babyeater vendor and the lazybastard Vendors, regardless of how those versions compare, the management tool can be told to stay inside the babyeater namespace for package updates for foo (or be told to ignore vendor-ness completely and gobble the highest versioned packaged based on version comparison rules). If we had a way to authoritatively identify vendors ( hint gpg sigs ) then you could programmatically instruct a depsolver to always prefer updates from the vendor of the package for which you already have packages installed. If such functionality was possible, I bet it would be implemented in a yum plugin called protectvendor. -jef"I'm not a glass is half-empty of half-full sort of person. My glass is filled to the brim.. one part tequila, one part nerve gas"spaleta -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
