* 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.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vdb5mhiu....@mid.deneb.enyo.de
