~$ apt-cache policy libconfigreader-simple-perl
libconfigreader-simple-perl:
Installed: 1.28-2
Candidate: 1.28-2
Version table:
1.28-2 0
500 http://localhost sid/main Packages
*** 1.28-2 0
100 /var/lib/dpkg/status
Aptitude keeps reporting that the package can be updated, from 1.28-2 to 1.28-2
?! When I say go, it claims that it has successfully upgraded it - but it then
reports that the package is upgradeable - from 1.28-2 to 1.28-2 ... What on
earth is going on here? I'm not even sure if this is a bug in this package, or
in aptitude, or somewhere else.
Thanks for your bug report, that's interesting indeed :)
Some quick thoughts:
* I'm sure this is not a problem of the package, the package is not
doing anything else than having a version, the handling of upgrades
etc. is handled by apt* and friends.
* I'm not surprised that aptitude offers an upgrade; in my experience
packages from a mirror have precedence over locally installed
packages, even if they have the same version.
* The interesting thing now is why the upgrade doesn't happen; some
random thoughts: Do you have some pinning in /etc/apt/preferences{,.d/*}?
Does an aptitude update change anything? Doesn apt-get behave the
same way as aptitude? What happens if you exchange localhost with
some "real" mirror?
Maybe someone else has additional ideas.
Cheers,
gregor
On Mon, 22 Mar 2010 14:44:48 +0100 gregor herrmann <gregoa@debian.org> wrote: I figured as much; I'm just trying to understand why I only see this problem with this particular package. Everything's both localhost and from the mirror; aptitude is pointed toward an approx installation running on localhost. No. No change after repeated updates. Same with apt-get. Same. So, in summary: My system endlessly tries to upgrade the package to the same version, even after repeated updating, with both apt and aptitude, no pinning, and even when cutting approx out of the loop and using a mirror directly. Celejar
Thanks for your quick reply. And I'm also curious to find out what's happening here :) Ok. Ok. Ok. Hm, any difference with upgrade/dist-upgrade/reinstall? Ok. Thanks for trying all these options, TBH, I'm running out of ideas ... Cheers, gregor
On Mon, 22 Mar 2010 22:59:05 +0100 gregor herrmann <gregoa@debian.org> wrote: ... I tried 'aptitude dist-upgrade libconfigreader-simple-perl' - same. I then purged the package, and then reinstalled it. As soon as aptitude finished the installation and reloaded the cache, guess what ;) It reported one package available to be upgraded ... Thanks for walking me through this. I suppose that it's possible that I've messed up something manually, but I'm really not much of a low-level tinkerer, and almost all tweaks that I do are by the book. Celejar
reassign 574956 aptitude thanks Celejar <celejar@gmail.com> writes: In any case, bug reassigned to aptitude for now. The bug might well be in some library, but the aptitude maintainers should know more about this than the Perl Group ;) Regards, Ansgar
... No. I removed the debs both from /var/cache/apt/archives, as well as from the approx cache, and the problem remains. Fair enough! Celejar
FWIW, I just installed the package on another Sid machine, and the problem appears there, too. Celejar
On Wed, Apr 28, 2010 at 11:34:49PM -0400, Celejar <celejar@gmail.com> was heard to say: OK, I looked through the logs for this bug, and it sounds like an apt problem (since apt-get does the same thing). I'll reassign it over there. Daniel
package apt aptitude reassign 574956 apt thanks Hi Celejar and to the others involved! Is this the complete output of apt-get policy? From your description it sounds like bug #574072 and friends, but for this bug it would need a few more versions… Best regards / Mit freundlichen Grüßen, David Kalnischkies
~$ apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://localhost sid/non-free Translation-en_US
500 http://localhost sid/non-free Packages
release v=None,o=Unofficial Multimedia
Packages,a=unstable,n=sid,l=Unofficial Multimedia Packages,c=non-free
origin localhost 500 http://localhost sid/main Translation-en_US
500 http://localhost sid/main Packages
release v=None,o=Unofficial Multimedia
Packages,a=unstable,n=sid,l=Unofficial Multimedia Packages,c=main
origin localhost500 http://localhost sid/non-free Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=non-free
origin localhost
500 http://localhost sid/contrib Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=contrib
origin localhost
500 http://localhost sid/main Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=main
origin localhost
Pinned packages:
If there's any other information I can provide, just let me know.
Celejar
Thanks for your answer, it just that i have expressed my request in the wrong way - i thought of "apt-cache policy libconfigreader-simple-perl" in your first mail while asking if this output is complete… Sorry for the misunderstanding. Still the output is a bit suspicious: Debians non-free doesn't provide Translations (the translations are included in the Translation file for main) -- and additional debian doesn't provide an en_US Translation… So my next questions are: Which archives do you mirror in your localhost, is it the same if you replace localhost with the right archive and which software do you use to mirror the archives? (I remember a bugreport in which a mirror creater application messed up the files causing "unexpected" behavior of apt and friends) Best regards, David Kalnischkies
Sorry, see below.
I'm using approx. My approx.conf contains just:
debian http://ftp.us.debian.org/debian
multimedia http://www.debian-multimedia.org
This is what the apt-cache policy looks like:
$ apt-cache policy libconfigreader-simple-perl
libconfigreader-simple-perl:
Installed: 1.28-2
Candidate: 1.28-2
Version table:
1.28-2 0
500 http://localhost sid/main Packages
*** 1.28-2 0
100 /var/lib/dpkg/status
I changed my apt.sources to go directly to ftp.us.debian.org, and the
problem remains, with the apt-cache policy now looking like this:
$ apt-cache policy libconfigreader-simple-perl
libconfigreader-simple-perl:
Installed: 1.28-2
Candidate: 1.28-2
Version table:
1.28-2 0
500 http://ftp.us.debian.org sid/main Packages
*** 1.28-2 0
100 /var/lib/dpkg/status
Thanks,
Celejar
Celejar <celejar@gmail.com> writes:
Did you run apt-cache clean?
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.
Unless that issue was fixed?
MfG
Goswin
On Fri, 30 Apr 2010 04:13:15 +0200 Goswin von Brederlow <goswin-v-b@web.de> wrote: ... I assume you mean apt-get clean? I've just tried repeated combinations of apt-get clean / aptitude clean / aptitude update / aptitude upgrade and the problem remains. If there's an exact sequence you want me to try and verify, just let me know. Celejar
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@web.de>: 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
Wow, nice catch! I can do this, in fact I've just committed the change to our subversion repository. Should I wait with an upload a bit longer so others can use this as a testcase? Cheers, gregor
Hi! [...] 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 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
Guillem Jover <guillem@debian.org> writes:
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.
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
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 <guillem@debian.org>: 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… 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… Best regards, David Kalnischkies
I don't agree with this. The perl API preserve all the information required to be able to output exactly the same string that has been parsed and I don't see why the C part should not be able to do the same. Please find attached a patch that implements this. I added non-regression tests and verified that the epoch is preserved with the package that generated this request. I'd like to commit this to the master branch so a review is welcome. That said maybe dpkg-gencontrol should indeed simplify the output but that's a different matter. I recorded that wish in a somewhat related bug report. Cheers,
* Guillem Jover: 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. It would be great with dpkg and APT (and thus dak by extension) could finally use exactly the same code. If that is not possible, policy could be changed to allow only versions where both implementtions agree.
Do you have a pointer? Can you record this as a bugreport if there's none on this topic? The "epoch comparison algorithm" is a simple integer comparison so I'm not sure what difference we can have. Since I'm not sure what kind of difference we're speaking about I don't know whether dpkg has to be fixed or the policy. Cheers,
* Raphael Hertzog:
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.
Florian Weimer <fw@deneb.enyo.de> writes:
Well, this is wrong if one is to take the wording of policy to mean a C
type. An "unsigned integer" has the same size on i386 and amd64.
An epoch is defined as
epoch
This is a single (generally small) unsigned integer. It may be
omitted, in which case zero is assumed. If it is omitted then the
upstream_version may not contain any colons.
Lets remove the "generally" from policy so we can truely declare this
case as insane.
MfG
Goswin