[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: