[Yum-devel] RFC: Package object comparison -- do we need a slight change?

[seth vidal]

On Wed, 2006-10-11 at 22:08 -0400, Jeremy Katz wrote:
> So, as it stands right now, we have nice and rich comparison operators
> for packages.  foo-1.0-1 < foo-2.0-1 works nicely, etc.  The problem
> starts to come in when we get to equality with multiple arches.  Should
> foo-1.0-1.i386 == foo-1.0-1.x86_64?  Right now, the answer is yes, but
> that breaks trying to see if a specific package is already found in a
> list and other such cases.
> 
> So, the options (I can think of) are basically
> a) Live with it -- if you're trying to check if a package is in a list
> or if two packages are actually the same, you have to do equality and
> then an arch check.  I think this kind of breaks the principle of least
> surprise and is likely to lead to bugs in API users[1]
> b) Make the change so that equality of packages also takes into account
> arch[2].  This would be a slight semantic change, but I'm not sure I can
> think of a case where this _wouldn't_ be what you expect

so if someone says:
 if po == po2:
   foo()
 if po > po2:
   bar()
 if po < po2:
   baz()


all of the above could return false.

which seems, counter-intuitive to me.

I get where you're coming from about the comparison - I'm just worried
about the next requested step:
  - take arch into account when dealing with < > comparisons

b/c I can imagine someone's code wanting to do:
 if po > po2:
    install(po)

 and that being a bad thing b/c we're not realizing that po == foo.i386
and po2 == foo.x86_64

It almost feels like we should never allow rich comparison against
non-matching archs. Which might be an argument for how to keep someone
from doing this accidentally.

I'd like to hear more people's thoughts, though.

-sv