Bug#645579: apt-get upgrade keeps upgradable package
David Kalnischkies wrote: Bob Proulx wrote: Recommends: libm17n-0 (= [-1.5.0)-] {+1.6.3)+} The Recommends here is the bad thing: I have libm17n-0 1.6.2-3 installed. It should satisfy both the old and the new Recommends since both are = relationships. Right? No. I was wrong. I did *not* have 1.6.3 installed. I had 1.6.2-3 installed. My reading played tricks with me and I read that wrong repeatedly. You have to look very close. :) Oh! I see it now. And the answer to my question should have been NO because 1.6.2 isn't 1.6.3. I kept looking at 1.6.2 and seeing 1.6.3. That is why I thought the Recommends was satisfied. But it wasn't because .2 isn't .3. My bad! I don't know why I did that repeatedly but I did. Thinking that I had 1.6.3 installed was the root cause of my confusion on this problem and it continued until just now. As 1.50 1.6.2 1.6.3 is true, the recommends is NOT satisfied any more in the new version as long as apt can't upgrade libm17n-0 to a version = 1.6.3 together with the upgrade of m17n-contrib. Typo: s/1.50/1.5.0/ It's clear now. My confusion reading .2 as .3 existed entirely between my chair and monitor. If you imagine that I had libm17n-0 1.6.3 installed then you can see the source of my questions. Sorry for the noise. I see that today the m17n-lib package 1.6.2-3 migrated into Testing and that 1.6.3-1 was uploaded to unstable. With that upload the Recommends problem is resolved because 1.6.3 (emphasis on the .3) is now available. And it does: # apt-get upgrade ... The following packages will be upgraded: libm17n-0 m17n-contrib 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. lets use a simple self-made example instead: Thanks for the example, which I understood and agreed with completely but had nothing to do with the problem I was having. However you couldn't have known my actual problem given our exchanges here and gave it a great attempt! :-) Thanks for all of the explanation. Bob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645579: apt-get upgrade keeps upgradable package
On Wed, Oct 19, 2011 at 23:37, Bob Proulx b...@proulx.com wrote: 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 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. You have to look very close. :) You have installed libm17n-0 in version 1.6.2-3 The old version of m17n-contrib recommends = 1.5.0 The new version of m17n-contrib recommends = 1.6.3 As 1.50 1.6.2 1.6.3 is true, the recommends is NOT satisfied any more in the new version as long as apt can't upgrade libm17n-0 to a version = 1.6.3 together with the upgrade of m17n-contrib. 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? As i don't know the reasoning behind m17n-contrib recommends (yet alone i don't even know the package itself) lets use a simple self-made example instead: You have a good game and it can be played in single- and multiplayer. The game only recommends the server-package needed for multiplay as you could have a lot of fun even without ever being connected to a network just by playing the singleplayer campaign. As it can have strange effects if server and game version doesn't match the server denies clients to join a game with a higher version then the server has (as he just doesn't know how to handle them correctly). The situation therefore: Package: game Version: 1 Recommends: server (= 1) Package: server Version: 1 No let the maintainer upload a new version of game Package: game Version: 2 Recommends: server (= 2) If you install this new version now without waiting for a new version for server, too, you loose the ability to join games on your own server. That's a loose of functionality you don't want in 'upgrade'… Or for a real example look at how linux-image-.* packages containing the kernel recommends to install the firmware-linux-free package. What does it help to 'upgrade' to a new kernel if the new kernel can't cope with the old firmware files - parts of your hardware wouldn't be usable anymore after this upgrade! (Still not everyone on the planet has the same hardware, so you might be lucky and survive without the firmware in the first place hence it is just a recommends) Best regards David Kalnischkies P.S.: Harshula, debian-ment...@lists.debian.org [0] and http://mentors.debian.net/ might be helpful to find a sponsor. Might be that Axel Beckert as the original reporter (and therefore with a high interest on that) is interested in helping you out, too. [0] http://lists.debian.org/debian-mentors/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645579: apt-get upgrade keeps upgradable package
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645579: apt-get upgrade keeps upgradable package
On Wed, 2011-10-19 at 15:37 -0600, Bob Proulx wrote: 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 OK, that makes sense. I need to create a new subpackage m17n-lib-mimx to fix Bug #582797 but, cause I'm a Debian Maintainer, I don't have permission to upload the new subpackage. cya, # -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645579: apt-get upgrade keeps upgradable package
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 -- System Information: 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