Code review comment for lp:~jelmer/launchpad/noversion

On 12.03.2010 19:52, Jelmer Vernooij wrote:
>> On 12.03.2010 11:43, Jelmer Vernooij wrote:
>>> This test already existed, I've just changed it to use assertEquals.
>> Right, but you changed the implemention of the tested class, so this is
>> a genuine test failure ;)
> Yep - thanks, I'm not sure how I missed that.
>
>>> Older versions of Launchpad also had this behaviour and it's required by
>> Debian policy. It looks like older versions of python-debian considered 1.0 <
>> 1.0-0.
>> OK. But the is question why this "relaxed equality comparison" was
>> introduced and even tested, and if we can remove it again.
> It was inherited from sourcerer and this is mainly a theoretical situation. "0" should never be used as the debian revision and it would only ever apply anyway if somebody changed a native package to no longer be native while keeping the upstream version the same *and* using 0 for the debian revision.
>
> Still, it would be nice to get right just in case somebody happens to ever do something like that. It would be confusing if dpkg and launchpad behaved differently. I've filed a bug against apt in debian about this and noted it in the source code.

OK, so, what shall we do with this test failure? Adjust the test or
change the __cmp__ method of the tested class?

I have no clue if the new comparison may have any side effects on other
code -- I simply don't understand enough about Soyuz and the fine
details about Debian packages in general.

Can/should we simply ensure that version strings without the "-0" are
rejected? That would make the test obsolete. (Do we already have
packages where this "-0" is missing?)

If we keep the new comparison: Can it happen that we have two package
versions 1.0 and 1.0-0? How would Launchpad deal with these packages?
And how would apt, dpkg and other package management tools deal with
these versions?

Abel