Re: [#365584] mailman installs, but is still reported as upgradeable afterwards
On Mon, May 01, 2006 at 10:27:41AM +0100, Martin A. Brooks wrote:
> hannon:~# apt-get install mailman
> Reading package lists... Done
> Building dependency tree... Done
> Suggested packages:
> python2.3-korean-codecs python2.2-korean-codecs python-japanese-codecs
> listadmin
> The following packages will be upgraded:
> mailman
[cut]
> shannon:~# apt-get upgrade
> Reading package lists... Done
> Building dependency tree... Done
> The following packages will be upgraded:
> mailman
[cut]
> Preparing to replace mailman 2.1.7-2.1.8rc1-1 (using
> .../mailman_0%3a2.1.7-2.1.8rc1-1_i386.deb) ...
[cut]
> ...and so on. Subsequent upgrades simply repeat the installation
> procedure.
I noticed the same behavior using aptitude. I suspect that the reason is
misinterpretting epoch by APT library. Debian Policy says that:
"epoch [...] may be ommitted, in which case zero is assumed".[1]
Current mailman version is 0:2.1.7-2.1.8rc1-1. APT says, that installed
package has version 2.1.7-2.1.8rc1-1. And 0:2.1.7-2.1.8rc1-1 is available.
Then it consider 0:foo bigger than foo and trying to upgrade package
to 0:foo version.
Output of apt-cache policy confirms this suspection:
arturcz@blabluga:~$ apt-cache policy mailman
mailman:
Installed: 2.1.7-2.1.8rc1-1
Candidate: 0:2.1.7-2.1.8rc1-1
Version table:
0:2.1.7-2.1.8rc1-1 0
500 http://http.us.debian.org unstable/main Packages
500 http://www.rotfl.eu.org unstable/main Packages
*** 2.1.7-2.1.8rc1-1 0
100 /var/lib/dpkg/status
So, I think that this bug should be reassigned to apt package.
Best regards
Artur
[1] http://blabluga/doc/debian-policy/policy.html/ch-controlfields.html#s-f-Version
--
Nie wszystko dioda, co sie świeci
/z pamiętnika administratora/
Reply to: