Bug 152127 – atoms are inconsistant for version comparison depending on operation.

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Brian Harring (RETIRED) 2006-10-20 09:00:13 UTC]

assuming sys-apps/portage-2.1.2_pre3-r5 is the max version available;

emerge -pv '=sys-apps/portage-2.1.2_pre3-r5'
portage-2.1.2_pre3-r5 (correct)

emerge -pv '=sys-apps/portage-2.1.2.0_pre3-r5'
no matches (inconsistant compared to >= behavior)

emerge -pv '>=sys-apps/portage-2.1.2_pre3-r5'
portage-2.1.2_pre3-5 (correct)

emerge -pv '>=sys-apps/portage-2.1.2.0_pre3-r5'
portage-2.1.2_pre3-r5 (inconsistant compared to = behavior)

Now... the tricky thing is that if .0 is implicit, that means multiple ebuilds in the same repository (literal multiple files) can be the exact same version, thus boning up portage internals and making select ebuilds implementation dependant for if they're selected or not.

enjoy...

[Comment 1 Brian Harring (RETIRED) 2006-10-23 03:11:59 UTC]

*bump*

I know y'all are active, time to comment ;)

[Comment 2 Zac Medico 2006-10-23 14:04:50 UTC]

(In reply to comment #0)
> emerge -pv '=sys-apps/portage-2.1.2.0_pre3-r5'
> no matches (inconsistant compared to >= behavior)

The = operator should force a literal match imo.

> emerge -pv '>=sys-apps/portage-2.1.2.0_pre3-r5'
> portage-2.1.2_pre3-r5 (inconsistant compared to = behavior)

I think we should fix this case.

[Comment 3 SpanKY 2006-10-23 14:12:22 UTC]

i think the current behavior is correct ... '=' forces very specific match while >= allows the implicit .0 to work ...

[Comment 4 Zac Medico 2006-10-23 14:22:56 UTC]

(In reply to comment #3)
> i think the current behavior is correct ... '=' forces very specific match
> while >= allows the implicit .0 to work ...

Oh yeah, that's what I meant, actually.

[Comment 5 Brian Harring (RETIRED) 2006-10-23 15:24:18 UTC]

(In reply to comment #3)
> i think the current behavior is correct ... '=' forces very specific match
> while >= allows the implicit .0 to work ...

There is no implicit .0 in the examples demonstrating the inconsistancy however; for =, 1.2.0 != 1.2

For >=, for the lower bound, 1.2.0 == 1.2

Think y'all are missing that point; to portage, 1.2 < 1.2.0, yet '>' reverses that (emerge -p '>sys-apps/portage-2.1.2.0_pre6-r6' gets '2.1.2_pre6-r7'); so... as said, in one spot portage things 1.2.0 != 1.2, another spot it thinks 1.2.0 == 1.2

Be consistant.

[Comment 6 Zac Medico 2006-12-06 10:38:58 UTC]

In svn r5175 I've fixed it so that match_to_list = behavior is now consistent with >= and <=.

[Comment 7 Zac Medico 2006-12-07 13:02:31 UTC]

I've reverted r5175 and in svn r5205 I've changed it so that vercmp gives less value to implcit .0, so two versions that aren't literally equal are not ambiguously given the same value (in sorting, for example).

[Comment 8 Zac Medico 2006-12-08 14:12:46 UTC]

This has been released in 2.1.2_rc3.

[Comment 9 Ciaran McCreesh 2006-12-31 08:56:19 UTC]

Does this mean that 1.0.0_alpha1 > 1.0?

[Comment 10 Zac Medico 2006-12-31 09:21:06 UTC]

(In reply to comment #9)
> Does this mean that 1.0.0_alpha1 > 1.0?

Yes, unfortunately it's true now.  Perhaps the fix in r5175 leads to less ambiguity?

[Comment 11 Ciaran McCreesh 2006-12-31 09:33:43 UTC]

(In reply to comment #10)
> (In reply to comment #9)
> > Does this mean that 1.0.0_alpha1 > 1.0?
> 
> Yes, unfortunately it's true now.  Perhaps the fix in r5175 leads to less
> ambiguity?

Wasn't a complaint, was just making sure that that was how you'd implemented things before I changed Paludis. Yes, it's slightly weird, but it's also the only sane consistent solution.