repotag in EPEL

[Jeff Spaleta]

On 5/1/07, Rex Dieter <rdieter at math.unl.edu> 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