Guillem Jover <guil...@debian.org> writes:
> Hi!
>
> On Fri, 2010-04-30 at 12:56:08 +0200, David Kalnischkies wrote:
>> 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)
>
> [...]
>
>> 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() )
>
> The same problem arises with non-significant zeros before digits, for
> example:
>
> 0.001 == 0.1 == 00:000.1
>
> Although this might be trickier to see in the wild, as dpkg itself
> would not normalize these versions, but an unknowing packager could
> generate those (somehow) thinking they are different.
I don't think 0.001 and 0.1 are identical. They should only compare as
equal. If you have 2 packages with those versions then that means you
have 2 different packages. So apt is totaly right in treating them
differently. But for apt to do that dpkg has to keep the version string
as it is even if it contains non-significant zeroes. The zeroes might
also be part of the upstream version so maintainers might not have much
control over it and the debian version should not differ from upstream.
>> 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â¦).
>
> 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. And it seems that
> apt might need to consider the other equivalent versions too.
>
> regards,
> guillem
On the other hand the epoch is 100% maintainer controlled. So Debian can
make a policy how they are to be used and treated. Since a zero epoch
indeed is redundant and confusing, to both users and application it
turns out :), I agree with you there. They should not end up in
debs. But I would go one step further. I would give an error if a
explicit zero epoch is being used. If they are not allowed in debs then
why allow them in source? They are just as confusing there and (bad)
maintainer might even wonder where their zero epoch disapeared to. If
you don't push the maintainers nose into it how will they ever learn?
MfG
Goswin
--
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/874oirj46c....@frosties.localdomain
