Subject: Bug#216768: apt: Confirmed under Lenny with several sources and pinning

From: Ivan Vilata i Balaguer <[email-masked]>
Date: Mon, 02 Nov 2009 09:56:48 +0000

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  libc6                        2.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-14            Compression method of 7z format in
ii  python-apt            0.7.7.1+nmu1       Python interface to libapt-pkg

-- no debconf information

---

From: Julian Andres Klode <[email-masked]>
Date: Mon, 02 Nov 2009 14:26:59 +0100

> ``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.

-- 
Julian Andres Klode - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

---

From: David Kalnischkies <[email-masked]>
Date: Mon, 2 Nov 2009 16:40:00 +0100

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 <[email-masked]>:
> 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

---

From: Vincent Lefevre <[email-masked]>
Date: Mon, 2 Nov 2009 17:13:23 +0100

> "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.

> (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.

> Could we agree on that it is a (very) minor bug?

Yes.

-- 
Vincent Lefèvre <[email-masked]> - 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)

---

From: "Jesús M. Navarro" <[email-masked]>
Date: Mon, 2 Nov 2009 21:32:34 +0100

Hi, David:

> Hi all,

[...]

> 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.

---

From: Ivan Vilata i Balaguer <[email-masked]>
Date: Mon, 2 Nov 2009 21:10:14 +0100

> 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/