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

[David Kalnischkies]

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-v-b at 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