Bug#574956: dpkg drops zero-epoch in status file

[Florian Weimer]

* Raphael Hertzog:

> On Mon, 03 May 2010, Florian Weimer wrote:
>> But I think all implementations (except an obscure Ocaml one) agree on
>> the first equality.  Leading zeros are not significant here.
>> 
>> On top of that, dpkg's epoch comparison algorithm yields different
>> results on different architectures, and does not actually implement
>> what is specified in policy.  This has been known for a while.
>
> Do you have a pointer? Can you record this as a bugreport if there's
> none on this topic?

Well, I can't find the previous discussions in all cases, but here are
the discrepancies between apt/dak and dpkg that I'm aware of:

* 1-0 vs 1

$ python -c 'import apt_pkg; apt_pkg.init(); print apt_pkg.VersionCompare("1", "1-0")'
-1
$ dpkg --compare-versions '1' = '1-0'; echo $?
0

See <http://lists.debian.org/debian-dpkg/2009/02/msg00038.html>

This appears to be an apt bug, so I filed #580036.

* 0:1 vs 1

This appears to have been fixed.  (IIRC, apt treated those versions as
distinct.)  Therefore, the epoch stripping should not actually matter.

* Integer overflow in epoch handling

(i386)$ dpkg --compare-versions 4294967296:1 '>>' 4294967295:1 ; echo $?
1
(amd64)$ dpkg --compare-versions 4294967296:1 '>>' 4294967295:1 ; echo $?
0

The problem is that the size of long is archtecture-specific, and that
there is no proper error handling.  apt is not affected by this.

This appears to be a dpkg bug, filed as #580038.