Bug#216768: apt: Confirmed under Lenny with several sources and pinning
Package: apt Version: 0.7.20.2+lenny1 Followup-For: Bug #216768 My APT setup includes sources from Lenny (stable) and Squeeze (testing), pinned so that only certain packages get pulled from testing. I have ``apticron`` installed and since I made the mixed setup with pinning, it reports that ``dash`` and ``diffutils`` are pending an upgrade, when neither of them are installed. It happens that both packages are essential in Squeeze, but not in Lenny. If I install the Lenny version of ``dash`` and try to remove it with Aptitude, it insists in the installed package being essential, which is untrue. Forcing the removal of ``dash`` and ``diffutils`` reverts the system to the same state (i.e. ``apticron`` recommending the upgrade of the uninstalled packages). -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture i386; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Acquire ; APT::Acquire::Translation environment; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::Default-Release stable; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::userstatus status.user; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::dpkg /usr/bin/dpkg; Dir::Log var/log/apt; Dir::Log::Terminal term.log; DPkg ; DPkg::Pre-Install-Pkgs ; DPkg::Pre-Install-Pkgs:: /usr/bin/apt-listchanges --apt || test $? -ne 10; DPkg::Pre-Install-Pkgs:: /usr/sbin/dpkg-preconfigure --apt || true; DPkg::Tools ; DPkg::Tools::Options ; DPkg::Tools::Options::/usr/bin/apt-listchanges ; DPkg::Tools::Options::/usr/bin/apt-listchanges::Version 2; -- /etc/apt/preferences -- Package: * Pin: release a=lenny-backports Pin-Priority: 200 Package: drupal6 Pin: release a=lenny-backports Pin-Priority: 999 Package: * Pin: release a=testing Pin-Priority: 190 Package: prosody Pin: release a=testing Pin-Priority: 999 Package: liblua5.1-sec0 Pin: release a=testing Pin-Priority: 999 -- /etc/apt/sources.list -- deb http://ftp.us.debian.org/debian lenny main deb-src http://ftp.us.debian.org/debian lenny main deb http://security.debian.org/ lenny/updates main deb-src http://security.debian.org/ lenny/updates main ## XNX by=ivan date=2009-10-30 deb http://www.backports.org/debian lenny-backports main deb http://ftp.us.debian.org/debian testing main ## /XNX -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (190, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18.8-linode16 (SMP w/4 CPU cores) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apt depends on: ii debian-archive-keyring 2009.01.31 GnuPG archive keys of the Debian a ii libc62.7-18 GNU C Library: Shared libraries ii libgcc1 1:4.3.2-1.1 GCC support library ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 apt recommends no packages. Versions of packages apt suggests: pn apt-doc none (no description available) ii aptitude 0.4.11.11-1~lenny1 terminal-based package manager pn bzip2 none (no description available) pn dpkg-dev none (no description available) ii lzma 4.43-14Compression method of 7z format in ii python-apt0.7.7.1+nmu1 Python interface to libapt-pkg -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#216768: apt: Confirmed under Lenny with several sources and pinning
Am Montag, den 02.11.2009, 09:56 + schrieb Ivan Vilata i Balaguer: Package: apt Version: 0.7.20.2+lenny1 Followup-For: Bug #216768 My APT setup includes sources from Lenny (stable) and Squeeze (testing), pinned so that only certain packages get pulled from testing. I have ``apticron`` installed and since I made the mixed setup with pinning, it reports that ``dash`` and ``diffutils`` are pending an upgrade, when neither of them are installed. It happens that both packages are essential in Squeeze, but not in Lenny. If I install the Lenny version of ``dash`` and try to remove it with Aptitude, it insists in the installed package being essential, which is untrue. Forcing the removal of ``dash`` and ``diffutils`` reverts the system to the same state (i.e. ``apticron`` recommending the upgrade of the uninstalled packages). The problem is that the essential state is package specific and not version specific. This means that as long as there is one essential version of a package, all versions are considered essential. But anyway, dash and diffutils are essential in Squeeze, so you must have them installed if you want to install software from squeeze as such software may depend on them implicitly. Maybe it helps to pin those packages with priority -1. If not, it would be an idea to make this possible so people could manually overwrite essential packages. You could also try to use another package manager such as cupt or smart, and see if they do what you want. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture i386; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Acquire ; APT::Acquire::Translation environment; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::Default-Release stable; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::userstatus status.user; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::dpkg /usr/bin/dpkg; Dir::Log var/log/apt; Dir::Log::Terminal term.log; DPkg ; DPkg::Pre-Install-Pkgs ; DPkg::Pre-Install-Pkgs:: /usr/bin/apt-listchanges --apt || test $? -ne 10; DPkg::Pre-Install-Pkgs:: /usr/sbin/dpkg-preconfigure --apt || true; DPkg::Tools ; DPkg::Tools::Options ; DPkg::Tools::Options::/usr/bin/apt-listchanges ; DPkg::Tools::Options::/usr/bin/apt-listchanges::Version 2; -- /etc/apt/preferences -- Package: * Pin: release a=lenny-backports Pin-Priority: 200 Package: drupal6 Pin: release a=lenny-backports Pin-Priority: 999 Package: * Pin: release a=testing Pin-Priority: 190 Package: prosody Pin: release a=testing Pin-Priority: 999 Package: liblua5.1-sec0 Pin: release a=testing Pin-Priority: 999 -- /etc/apt/sources.list -- deb http://ftp.us.debian.org/debian lenny main deb-src http://ftp.us.debian.org/debian lenny main deb http://security.debian.org/ lenny/updates main deb-src http://security.debian.org/ lenny/updates main ## XNX by=ivan date=2009-10-30 deb http://www.backports.org/debian lenny-backports main deb http://ftp.us.debian.org/debian testing main ## /XNX -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (190, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18.8-linode16 (SMP w/4 CPU cores) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apt depends on: ii debian-archive-keyring 2009.01.31 GnuPG archive keys of the Debian a ii libc62.7-18 GNU C Library: Shared libraries ii libgcc1 1:4.3.2-1.1 GCC support library ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 apt recommends no packages. Versions of packages apt suggests: pn apt-doc none (no description available) ii aptitude 0.4.11.11-1~lenny1 terminal-based package manager pn bzip2 none (no description available) pn dpkg-dev none (no description available) ii lzma 4.43-14Compression method of 7z format in ii python-apt0.7.7.1+nmu1 Python interface to libapt-pkg -- no debconf information -- Julian Andres Klode - Debian Developer, Ubuntu Member See
Bug#216768: apt: Confirmed under Lenny with several sources and pinning
Hi all, On Tue, 1 Sep 2009, Santiago Vila wrote: Thanks, Raphael. This is clearly a problem in apt. Funny, i think it is a feature and i will try to describe why now. :) (I want to do it earlier, but i somehow managed to forget it...) 2009/11/2 Ivan Vilata i Balaguer i...@selidor.net: I have ``apticron`` installed and since I made the mixed setup with pinning, it reports that ``dash`` and ``diffutils`` are pending an upgrade, when neither of them are installed. It happens that both packages are essential in Squeeze, but not in Lenny. A user who mixed sources very likely mixes also packages. As a package doesn't need to depend on essential packages, apt tries to install in a dist(ribution)-upgrade ALL essential packages it can find in all sources to protect the user from dependency hell and as a bonus protect the user from doing something stupid: Removing a package which is/was/will be essential as it is maybe required by package on this system (who know how far your mixing goes, so better save than sorry as Ivan Vilata i Balaguer also said indirectly in his second message). On Tue, 1 Sep 2009, Vincent Lefevre wrote: I thought that the problem was more serious that it was: inconsistent database (since this is what it really appears to be). If the warning message were more detailed, one would not need to guess anything. The message says: This should NOT be done unless you know exactly what you are doing! So it is already open to the fact that it is maybe wrong to consider the package essential and that it is really safe to remove it, but APT thinks it is a lot better to require the user to use special forces (long confirm message, holds on uninstalled packages) in some cases instead of let the user destroy his system in many more cases. I don't see why a user could think of a inconsistent database after read this message, maybe APT could say that this package was/is/will _maybe_ an essential, but i guess this would be even more confusing to a user. Suggestions for a better wording? (I can't think of a better one) The real bug here showed by diff (and a few other before) is therefore something like this: New essential package A replaces old essential package B. (Package B is now a transitional package to A.) The user (with mixed sources) tries to deinstall package B and apt refuses that as it thinks B is essential - it doesn't take into account that A provides the same functionality as B. Could we agree on that it is a (very) minor bug? (btw: It is questionable if A really provides the absolutely exact functionality as B and is therefore really a full replacement but this is nothing i want to argue about now) Best regards / Mit freundlichen Grüßen, David DonKult Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544481: Bug#216768: apt: Confirmed under Lenny with several sources and pinning
On 2009-11-02 16:40:00 +0100, David Kalnischkies wrote: The message says: This should NOT be done unless you know exactly what you are doing! Well, this was The following essential packages will be removed. I found confusing. So it is already open to the fact that it is maybe wrong to consider the package essential and that it is really safe to remove it, but APT thinks it is a lot better to require the user to use special forces (long confirm message, holds on uninstalled packages) in some cases instead of let the user destroy his system in many more cases. I don't see why a user could think of a inconsistent database after read this message, maybe APT could say that this package was/is/will _maybe_ an essential, but i guess this would be even more confusing to a user. Suggestions for a better wording? (I can't think of a better one) Perhaps it should be said that the essential state is package specific and not version specific, because packages may depend on them implicitly. Otherwise users who *think* they know, but are not aware of such subtle points, could incorrectly assume that removing the package is OK. The real bug here showed by diff (and a few other before) is therefore something like this: New essential package A replaces old essential package B. (Package B is now a transitional package to A.) The user (with mixed sources) tries to deinstall package B and apt refuses that as it thinks B is essential - it doesn't take into account that A provides the same functionality as B. Could we agree on that it is a (very) minor bug? Yes. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#216768: apt: Confirmed under Lenny with several sources and pinning
Hi, David: On Monday 02 November 2009 16:40:00 David Kalnischkies wrote: Hi all, [...] The real bug here showed by diff (and a few other before) is therefore something like this: New essential package A replaces old essential package B. (Package B is now a transitional package to A.) The user (with mixed sources) tries to deinstall package B and apt refuses that as it thinks B is essential - it doesn't take into account that A provides the same functionality as B. Could we agree on that it is a (very) minor bug? No. At least not a package bug. Your very reasonement about why all essential packages are tried to be installed works here too: you have packages from versions N and N+1 where packages on N depend on essential foo and those on N+1 depend on the new essential bar which overrides foo. Then you can't gratuitously assume that even if bar is functionally-wise the same as foo versions on N will in fact be able to work with bar: you don't know how many or how deep changes where needed on N versions to make them work nicely with bar as they go N+1 (which it's, in fact, the main function of the very distribution effort: manage to get a disparaged bunch of packages to smoothly work together). So I don't think that's a bug but an unsupported corner-case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#216768: apt: Confirmed under Lenny with several sources and pinning
David Kalnischkies (el 2009-11-02 a les 16:40:00 +0100) va dir:: A user who mixed sources very likely mixes also packages. As a package doesn't need to depend on essential packages, apt tries to install in a dist(ribution)-upgrade ALL essential packages it can find in all sources to protect the user from dependency hell and as a bonus protect the user from doing something stupid: Removing a package which is/was/will be essential as it is maybe required by package on this system (who know how far your mixing goes, so better save than sorry as Ivan Vilata i Balaguer also said indirectly in his second message). Umm, I forgot to issue the dist-upgrade command after setting up the pinning, and that's why the new essential packages weren't installed. However, running ``aptitude dist-upgrade`` doesn't install the new essential packages, while ``apt-get dist-upgrade`` does. Do you think I should report this as a bug in Aptitude? Thanks for your comments, :: Ivan Vilata i Balaguer -- http://ivan.lovesgazpacho.net/ signature.asc Description: Digital signature
