Subject: libconfigreader-simple-perl: keeps upgrading - to the same version!
Date: Mon, 22 Mar 2010 09:13:53 -0400
Package: libconfigreader-simple-perl
Version: 1.28-2
Severity: normal
~$ 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.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.34-rc1-lizzie-00005-g522dba7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libconfigreader-simple-perl depends on:
ii perl 5.10.1-11 Larry Wall's Practical Extraction
libconfigreader-simple-perl recommends no packages.
libconfigreader-simple-perl suggests no packages.
-- debconf-show failed
Acknowledgement sent
to gregor herrmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Perl Group <[email protected]>.
(Mon, 22 Mar 2010 13:48:06 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: libconfigreader-simple-perl: keeps upgrading - to
the same version!
Date: Mon, 22 Mar 2010 14:44:48 +0100
On Mon, 22 Mar 2010 09:13:53 -0400, Celejar wrote:
> 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
--
.''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
`- Bones: "The man's DEAD, Jim!"
Acknowledgement sent
to Celejar <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Perl Group <[email protected]>.
(Mon, 22 Mar 2010 15:39:15 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: libconfigreader-simple-perl: keeps upgrading - to
the same version!
Date: Mon, 22 Mar 2010 11:31:46 -0400
On Mon, 22 Mar 2010 14:44:48 +0100
gregor herrmann <[email protected]> wrote:
> On Mon, 22 Mar 2010 09:13:53 -0400, Celejar wrote:
>
> > 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 figured as much; I'm just trying to understand why I only see this
problem with this particular package.
> * 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.
Everything's both localhost and from the mirror; aptitude is pointed
toward an approx installation running on localhost.
> * The interesting thing now is why the upgrade doesn't happen; some
> random thoughts: Do you have some pinning in /etc/apt/preferences{,.d/*}?
No.
> Does an aptitude update change anything? Doesn apt-get behave the
No change after repeated updates. Same with apt-get.
> same way as aptitude? What happens if you exchange localhost with
> some "real" mirror?
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
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Acknowledgement sent
to gregor herrmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Perl Group <[email protected]>.
(Mon, 22 Mar 2010 22:00:03 GMT) (full text, mbox, link).
On Mon, 22 Mar 2010 11:31:46 -0400, Celejar wrote:
> > * 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 figured as much; I'm just trying to understand why I only see this
> problem with this particular package.
Thanks for your quick reply.
And I'm also curious to find out what's happening here :)
> > * 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.
> Everything's both localhost and from the mirror; aptitude is pointed
> toward an approx installation running on localhost.
Ok.
> > * The interesting thing now is why the upgrade doesn't happen; some
> > random thoughts: Do you have some pinning in /etc/apt/preferences{,.d/*}?
> No.
Ok.
> > Does an aptitude update change anything? Doesn apt-get behave the
> No change after repeated updates. Same with apt-get.
Ok.
Hm, any difference with upgrade/dist-upgrade/reinstall?
> > same way as aptitude? What happens if you exchange localhost with
> > some "real" mirror?
> Same.
Ok.
> 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.
Thanks for trying all these options,
TBH, I'm running out of ideas ...
Cheers,
gregor
--
.''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
`- NP: Spider Murphy Gang: Mit'n Frosch im Hois und Schwammerl in die Knia
Acknowledgement sent
to Celejar <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Perl Group <[email protected]>.
(Mon, 22 Mar 2010 23:42:07 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: libconfigreader-simple-perl: keeps upgrading - to
the same version!
Date: Mon, 22 Mar 2010 19:38:20 -0400
On Mon, 22 Mar 2010 22:59:05 +0100
gregor herrmann <[email protected]> wrote:
> On Mon, 22 Mar 2010 11:31:46 -0400, Celejar wrote:
...
> Hm, any difference with upgrade/dist-upgrade/reinstall?
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 trying all these options,
> TBH, I'm running out of ideas ...
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
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Subject: Re: Bug#574956: libconfigreader-simple-perl: keeps upgrading - to the same version!
Date: Tue, 23 Mar 2010 16:27:35 +0900
reassign 574956 aptitude
thanks
Celejar <[email protected]> writes:
> gregor herrmann <[email protected]> wrote:
>> On Mon, 22 Mar 2010 09:13:53 -0400, Celejar wrote:
>> > 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 figured as much; I'm just trying to understand why I only see this
> problem with this particular package.
>
>> * 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.
>
> Everything's both localhost and from the mirror; aptitude is pointed
> toward an approx installation running on localhost.
>
>> * The interesting thing now is why the upgrade doesn't happen; some
>> random thoughts: Do you have some pinning in /etc/apt/preferences{,.d/*}?
>
> No.
>
>> Does an aptitude update change anything? Doesn apt-get behave the
>
> No change after repeated updates. Same with apt-get.
>
>> same way as aptitude? What happens if you exchange localhost with
>> some "real" mirror?
>
> 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.
A random idea: Does removing the .deb from /var/cache/apt/archives help?
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
Bug No longer marked as found in versions libconfigreader-simple-perl/1.28-2.
Request was from Ansgar Burchardt <[email protected]>
to [email protected].
(Tue, 23 Mar 2010 07:51:07 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: libconfigreader-simple-perl: keeps upgrading - to
the same version!
Date: Tue, 23 Mar 2010 09:12:35 -0400
On Tue, 23 Mar 2010 16:27:35 +0900
Ansgar Burchardt <[email protected]> wrote:
> reassign 574956 aptitude
> thanks
...
> A random idea: Does removing the .deb from /var/cache/apt/archives help?
No. I removed the debs both from /var/cache/apt/archives, as well as
from the approx cache, and the problem remains.
> 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 ;)
Fair enough!
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
FWIW, I just installed the package on another Sid machine, and the
problem appears there, too.
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Acknowledgement sent
to Daniel Burrows <[email protected]>:
Extra info received and forwarded to list.
(Thu, 29 Apr 2010 14:15:03 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: same problem on another machine
Date: Thu, 29 Apr 2010 07:10:29 -0700
On Wed, Apr 28, 2010 at 11:34:49PM -0400, Celejar <[email protected]> was heard to say:
> FWIW, I just installed the package on another Sid machine, and the
> problem appears there, too.
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
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Thu, 29 Apr 2010 15:00:03 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: keeps upgrading - to the same version
Date: Thu, 29 Apr 2010 16:56:32 +0200
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
Acknowledgement sent
to Celejar <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Thu, 29 Apr 2010 18:21:03 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: keeps upgrading - to the same version
Date: Thu, 29 Apr 2010 14:19:04 -0400
On Thu, 29 Apr 2010 16:56:32 +0200
David Kalnischkies <[email protected]> wrote:
> 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…
~$ 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
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Thu, 29 Apr 2010 21:21:15 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: keeps upgrading - to the same version
Date: Thu, 29 Apr 2010 23:17:59 +0200
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:
> 500 http://localhost sid/non-free Translation-en_US
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
Acknowledgement sent
to Celejar <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Thu, 29 Apr 2010 23:54:03 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: keeps upgrading - to the same version
Date: Thu, 29 Apr 2010 19:51:29 -0400
On Thu, 29 Apr 2010 23:17:59 +0200
David Kalnischkies <[email protected]> wrote:
> 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.
Sorry, see below.
> Still the output is a bit suspicious:
> > 500 http://localhost sid/non-free Translation-en_US
> 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'm using approx. My approx.conf contains just:
debian http://ftp.us.debian.org/debian
multimedia http://www.debian-multimedia.org
> (I remember a bugreport in which a mirror creater application messed
> up the files causing "unexpected" behavior of apt and friends)
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
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Acknowledgement sent
to Goswin von Brederlow <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 30 Apr 2010 02:15:03 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: keeps upgrading - to the same version
Date: Fri, 30 Apr 2010 04:13:15 +0200
Celejar <[email protected]> writes:
> On Thu, 29 Apr 2010 23:17:59 +0200
> David Kalnischkies <[email protected]> wrote:
>
>> 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.
>
> Sorry, see below.
>
>> Still the output is a bit suspicious:
>> > Â 500 http://localhost sid/non-free Translation-en_US
>> 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'm using approx. My approx.conf contains just:
>
> debian http://ftp.us.debian.org/debian
> multimedia http://www.debian-multimedia.org
>
>> (I remember a bugreport in which a mirror creater application messed
>> up the files causing "unexpected" behavior of apt and friends)
>
> 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
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
Acknowledgement sent
to Celejar <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 30 Apr 2010 03:33:10 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: keeps upgrading - to the same version
Date: Thu, 29 Apr 2010 23:31:20 -0400
On Fri, 30 Apr 2010 04:13:15 +0200
Goswin von Brederlow <[email protected]> wrote:
...
> Did you run apt-cache clean?
I assume you mean apt-get 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.
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
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 30 Apr 2010 11:00:08 GMT) (full text, mbox, link).
Subject: Bug#574956: dpkg drops zero-epoch in status file
Date: Fri, 30 Apr 2010 12:56:08 +0200
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 <[email protected]>:
> 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
Acknowledgement sent
to gregor herrmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 30 Apr 2010 12:24:04 GMT) (full text, mbox, link).
On Fri, 30 Apr 2010 12:56:08 +0200, David Kalnischkies wrote:
> /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)
Wow, nice catch!
> 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)
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
--
.''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
`- NP: Joan Baez: Wozu sind Kriege da
Acknowledgement sent
to Guillem Jover <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 30 Apr 2010 16:33:04 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: dpkg drops zero-epoch in status file
Date: Fri, 30 Apr 2010 18:31:42 +0200
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.
> 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
Acknowledgement sent
to Goswin von Brederlow <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sat, 01 May 2010 10:42:09 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: dpkg drops zero-epoch in status file
Date: Sat, 01 May 2010 12:40:27 +0200
Guillem Jover <[email protected]> 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
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sat, 01 May 2010 15:15:04 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: dpkg drops zero-epoch in status file
Date: Sat, 1 May 2010 17:12:12 +0200
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 <[email protected]>:
>> 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…
Best regards,
David Kalnischkies
Acknowledgement sent
to Raphael Hertzog <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 02 May 2010 15:39:05 GMT) (full text, mbox, link).
On Fri, 30 Apr 2010, Guillem Jover wrote:
> > 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.
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,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
Acknowledgement sent
to Florian Weimer <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 03 May 2010 09:27:07 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: dpkg drops zero-epoch in status file
Date: Mon, 03 May 2010 10:54:50 +0200
* Guillem Jover:
> 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.
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.
Acknowledgement sent
to Raphael Hertzog <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 03 May 2010 09:27:09 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: dpkg drops zero-epoch in status file
Date: Mon, 3 May 2010 11:24:27 +0200
On Mon, 03 May 2010, Florian Weimer wrote:
> 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.
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,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
Acknowledgement sent
to Florian Weimer <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 03 May 2010 10:03:07 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: dpkg drops zero-epoch in status file
Date: Mon, 03 May 2010 12:00:41 +0200
* Raphael Hertzog:
> On Mon, 03 May 2010, Florian Weimer wrote:
>> 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.
>
> Do you have a pointer? Can you record this as a bugreport if there's
> none on this topic?
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.
Acknowledgement sent
to Goswin von Brederlow <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Tue, 04 May 2010 03:00:46 GMT) (full text, mbox, link).
Subject: Re: Bug#574956: dpkg drops zero-epoch in status file
Date: Tue, 04 May 2010 04:59:11 +0200
Florian Weimer <[email protected]> writes:
> * 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
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.
> 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.
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