Re: Bug#574956: dpkg drops zero-epoch in status file
Just to be sure: I am talking here only about the behavior of
apt then it encounters multiple package stanzas which have
the same version number (compared as dpkg does it) -
in this case apt needs a way to identify if the stanza refers to
the same version (e.g. then it is shipped in unstable and testing)
or if the versions are different for whatever reason
(e.g. binary rebuilt without version number change).
To detect this it uses some information available in the Packages
file as well as in the status file and computes a hash over this
string. Included in this string are the dependencies - and in this
case a versioned dependency - and this versioned dependency is
not normalized, so stanzas about the same package seems to be
different for apt and it therefore installs the version with the highest
pin as the installed version seems to be outdated.
2010/4/30 Guillem Jover <firstname.lastname@example.org>:
>> 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…).
> I don't think dpkg should stop removing the zero-epoch, it would be
> redundant and confusing information. But it might be a good idea to
> make dpkg-gencontrol for example drop it on output.
Now the difference between status and Packages file is confusing.
Or the difference between debian/control and status, your choice.
So in my eyes It would be cool if the lowest possible toolchain
generating these stanzas does the reformatting once and for all
and dpkg/apt/every other tool doesn't need to handle x different
version schemes all by themselves again and again as this is a
total waste of resources… (developer time mostly) and
more than error prune as can be seen here…
apt-ftparchive for example would need to be told about versions
to be able to parse and normalize them in the same style dpkg does
it for the Packages files and i am pretty sure the other archivebuilders
doesn't care to much about version numbers until now too…
> And it seems that apt might need to consider
> the other equivalent versions too.
I currently think the easiest thing is to pull out the wooden hammer
and ignore for the hash all colons and zeros in the string.
At least it is better than ignoring the versions completely and
writing a full-blown version number normalizer just for this small
use case seems to be over-engineering…