Hello all :) We should have tried it ealier, i (and every other unstable/testing user) can reproduce it easily… It is just that the popcon is low so until now unspotted (popcon will race now drastically ;) )
The problem: To compare versions with the same version number apt generates a hash over a few informations which are available online and in dpkgs status file: all dependencies and the installation size. (as these are likely to change if this is another version) If we compare the "two" versions now: /var/lib/dpkg/status: Package: libconfigreader-simple-perl Installed-Size: 96 Replaces: squidtaild (<< 2.1a6-5.4) Depends: perl Conflicts: squidtaild (<< 2.1a6-5.4) to /var/lib/apt/lists/*_Packages: Package: libconfigreader-simple-perl Installed-Size: 96 Replaces: squidtaild (<< 0:2.1a6-5.4) Depends: perl Conflicts: squidtaild (<< 0:2.1a6-5.4) we can see that dpkg in his status file drops the zero-epoch. This doesn't change the semantic as zero-epoch and no epoch are considered equal, but as apt uses the string without deeper parsing at this stage this is a big difference in the hash. ( can be seen in apt-pkg/deb/deblistparser.cc VersionHash() ) Quick&Dirty workaround is to drop the zero-epoch in the package so the Packages and status file are equal again. (cc'ed perl group and last uploader, maybe they want to do that) The real solution is to either tell apt to strip out the zero-epoch for the hash or to tell dpkg to not remove the zero-epoch in status. It is relatively easy for apt to ignore the epoch for the hash as it is a simple hash and we don't need to care about false positive removes so apt still doesn't need to do expensive parsing here, but i want to ask dpkg maintainers (cc'ed and titled to grep their attension) for their opinion as this is maybe something they want to change instead in their logic for consistence… (through no zero epoch could be a change to be consistence…). 2010/4/30 Goswin von Brederlow <goswin-...@web.de>: > If there are multiple packages with the same version that aren't > identical then you get multiple entries in apt-cache policy like you > have. Apt will try to update to the package with the highest pin. But > the apt download cache assumes that a package version is unique and if a > file for libconfigreader-simple-perl 1.28-2 exists in your cache then > apt will reinstall that instead of downloading the different one from > ftp.us.debian.org. So every time it sees that ftp.us.debian.org has a > different package but then it installs the old one again. While it is not a good idea for usability reasons apt can handle multiple different versions with the same number. Two versions were never a problem as this happens all the time: The version from Packages and the version from the status file. In the handling of three and more versions with the same number but different hashes was a bug until recently ( #574072 ) which prevent the version merger to work correctly which is why i asked if the policy output is complete… Best regards / Mit freundlichen Grüßen David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org