Bug#645579: apt-get upgrade keeps upgradable package

October 17th, 2011 - 02:00 am ET by Bob Proulx | Report spam

Package: apt
Version: 0.8.15.9
Severity: normal

I have a very strange m17n-contrib package and apt-get upgrade
interaction. In an up to date Sid today with all other packages up to
date. apt-get won't offer m17n-contrib for an upgrade but only a
dist-upgrade. This can be recreated on my system by ensuring that the
previous is installed:

# dpkg -i m17n-contrib_1.1.12-2_all.deb

And then attempting an upgrade.

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
m17n-contrib
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

And then trying to upgrade. And of course dist-upgrade offers the
package for an upgrade okay.

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
m17n-contrib
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/544 kB of archives.
After this operation, 221 kB disk space will be freed.
Do you want to continue [Y/n]?

Is it possible to ask apt-get to supply more information about this
problem to understand why it won't offer this package for an upgrade
but only for a dist-upgrade? I tried this:

$ apt-get -o Debug::pkgProblemResolver=yes upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Entering ResolveByKeep
Keeping package m17n-contrib:amd64
The following packages have been kept back:
m17n-contrib
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

A debdiff of the packages doesn't show me anything that seems like it
should cause this behavior.

$ debdiff m17n-contrib_1.1.12-2_all.deb m17n-contrib_1.1.13-1_all.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/share/m17n/bo-ewts.mim
-rw-r--r-- root/root /usr/share/m17n/hi-vedmata.mim
-rw-r--r-- root/root /usr/share/m17n/icons/hi-vedmata.png
-rw-r--r-- root/root /usr/share/m17n/icons/si-transliteration.png
-rw-r--r-- root/root /usr/share/m17n/icons/te-apple.png
-rw-r--r-- root/root /usr/share/m17n/icons/uz-kbd.png
-rw-r--r-- root/root /usr/share/m17n/ks-inscript.mim
-rw-r--r-- root/root /usr/share/m17n/sa-iast.mim
-rw-r--r-- root/root /usr/share/m17n/si-singlish.mim
-rw-r--r-- root/root /usr/share/m17n/uz-kbd.mim

Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/m17n/icons/si-trans.png

Control files: lines which differ (wdiff format)

Depends: m17n-db (>= [-1.5.0)-] {+1.6.3)+}
Description: [-a-] multilingual text processing library - contributed database
Installed-Size: [-1400-] {+1184+}
Recommends: libm17n-0 (>= [-1.5.0)-] {+1.6.3)+}
Version: [-1.1.12-2-] {+1.1.13-1+}

I have only the stock apt.conf.d files present.

$ ls -log /etc/apt/apt.conf /etc/apt/apt.conf.d
ls: cannot access /etc/apt/apt.conf: No such file or directory
/etc/apt/apt.conf.d:
total 16
-rw-r--r-- 1 40 Apr 30 2010 00trustcdrom
-rw-r--r-- 1 430 Apr 5 2011 01autoremove
-rw-r--r-- 1 182 Oct 12 2008 70debconf
-rw-r--r-- 1 127 May 3 2010 90debsums

$ cat /etc/apt/apt.conf.d/*
APT::Authentication::TrustCDROM "true";
APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image.*";
"^kfreebsd-image.*";
"^linux-restricted-modules.*";
"^linux-ubuntu-modules-.*";
"^gnumach$";
"^gnumach-image.*";
};

Never-MarkAuto-Sections
{
"metapackages";
"restricted/metapackages";
"universe/metapackages";
"multiverse/metapackages";
"oldlibs";
"restricted/oldlibs";
"universe/oldlibs";
"multiverse/oldlibs";
};
};
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt || true";};
DPkg::Post-Invoke { "if [ -x /usr/bin/debsums ]; then /usr/bin/debsums --generate=nocheck -sp /var/cache/apt/archives; fi"; };

Thank you for maintaining apt-get.

Bob

Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-2-amd64 (SMP w/4 CPU cores)
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 apt depends on:
ii debian-archive-keyring 2010.08.28
ii gnupg 1.4.11-3
ii libc6 2.13-21
ii libgcc1 1:4.6.1-15
ii libstdc++6 4.6.1-15
ii zlib1g 1:1.2.3.4.dfsg-3

apt recommends no packages.

Versions of packages apt suggests:
ii apt-doc 0.8.15.9
ii aptitude 0.6.4-1
ii bzip2 1.0.5-7
ii dpkg-dev 1.16.1.1
ii lzma 4.43-14
ii python-apt 0.8.0
ii synaptic 0.75.3

To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Follow the discussion Replies

4 replies

Make a reply

Replies

#1 Bob Proulx

October 19th, 2011 - 05:50 pm ET | Report spam

Hi David,

I have CC'd the m17n-contrib maintainer on this message too.

David Kalnischkies wrote:

first of all: Thanks for your detailed bugreport!

Thanks! I tried to include the information that I would want when
receiving such a report.

"Unfortunately" I have to say that this "new" behavior is not a bug…

Thanks for taking the time to look into the problem. As long as the
reasoning behind it makes sense then that is fine. It didn't make
sense to me and looked like a deeper problem. (It still looks like it
to me. But I hope to get past that point.)

> Control files: lines which differ (wdiff format)
>
> Depends: m17n-db (>= [-1.5.0)-] {+1.6.3)+}
> Description: [-a-] multilingual text processing library - contributed database
> Installed-Size: [-1400-] {+1184+}
> Recommends: libm17n-0 (>= [-1.5.0)-] {+1.6.3)+}
> Version: [-1.1.12-2-] {+1.1.13-1+}

The Recommends here is the bad thing:
Currently libm17n-0 is only available in 1.6.2-3 -
this means with an upgrade of m17n-contrib now we would break
a previously satisfied Recommends which means the user might loose
functionality without expecting it

I am sorry but I am still not quite understanding this point. And I
would like to understand it. Please bear with me for a moment longer.

I have libm17n-0 1.6.2-3 installed. It should satisfy both the old
and the new Recommends since both are ">=" relationships. Right? And
it seems to do so okay. I can install either version of m17n-contrib
without any dependency breakage.

Also this seems to be a very common pattern for a lot of packages and
if it is a problem then it should be causing the problem very often.
They upgrade their version number and the version number of packages
they Depend and Recommend. If that is a problem for apt then I would
have expected to have seen it a lot. But instead this is the only
time I can ever remember having run into this behavior out of all of
the years.

as 'upgrade' should be really conservative with a motto like: "Just
get bugfixes, not new issues".

I am in complete agreement. I am a big advocate of the Stable
release. But I am running Sid in order to see and diagnose problems
earlier than the Stable release cycle. :-)

In this case isn't 'upgrade' maintained? The list of names of the
packages installed would be exactly the same both before and after.
Only the version number of exactly one package is increased. Isn't
that a safe upgrade?

I see that you are telling me that it is not that part but the
recommends version part that is the issue. But again there isn't a
change in name but only a change in version and that should be okay
for a safe upgrade shouldn't it?

(This carefulness regarding policy-breakage was introduced in 0.8.15.3)

All good.

If you wouldn't install Recommends by default or you don't have
libm17n-0 installed 'apt-get upgrade' would have the same result as
'dist-upgrade' as there is no policy to break, as it was already broken
and therefore we don't have to fear that the user will loose functionality
as it was already lost.

But libm17n-0 is installed in both cases. If the new package added a
recommends then I could see what you are saying. But it only upgrades
the version of the recommends. The recommends exists in both the old
and new packages.

I am sure you are not saying that any package with a recommends is not
a candidate for a safe upgrade. But that is what I am reading and so
I am confused.

(There is also no concept of less or more broken, policy breakage handling
is binary, either it's broken or not, so if just one Recommends or twenty
are missing is no difference for the "policy breakage detector")

Okay with that. I am still back at the beginning try to understand
why it is broken. :-)

That we have no debug message telling us something like this is a bumper
through, so followup versions will have a lovely debug-message added:
Policy breaks with upgrade of foobar < x.y -> x.y.z >
Thanks for the suggestion!

I was trying to turn on verbose debug output but there wasn't a straw
to grasp at. :-) I was just asking if there was a debug flag that
could be used to debug it further. More debug info is good.

Thanks also for your report again and sorry for closing it as
not-a-bug-but-a-feature, but i hope it get clear with this
description. If not feel free to ask/reopen it.

I can't tell you how many times I have closed a new bug report as not
a bug and so I know exactly how you feel. Sometimes I just tag them
as moreinfo and then come back later and close them after more
interaction. But that is a lot more work.

Bob

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Read all the answers

Bug#645579: apt-get upgrade keeps upgradable package

Replies

Similar topics