Bug#670900: apt-get upgrade bails out with E: Internal Error, No file name for gcc-4.7-base

[Guillem Jover <guillem@debian.org>]

On Mon, 2012-09-03 at 13:26:27 +0200, David Kalnischkies wrote:
> On Sun, Sep 2, 2012 at 6:29 PM, Guillem Jover <guillem@debian.org> wrote:
> > On Mon, 2012-04-30 at 09:52:43 +0200, Martin Steigerwald wrote:
> > I think this bug report should be serious, because once hit, apt cannot
> > recover itself in any way, it is pretty easy to get into, and the only
> > way to proceed is to run for example: «dpkg --configure --pending»,
> > but that might not be enough if the dependencies are not satisfiable.
> 
> Predependency for reproducing this seems to be that the unpacked package
> is (pseudo)essential. The thing is that APT tries to unpack a package,
> which is already unpacked, but it earlier decided that it doesn't need
> to download the package as it already here (unpacked) - so you see
> this error as APT can't find the file as it didn't download it
> (at least not in its usual location in your example).

It seems to be something else (?), in my tests I had the downloaded
packages in my apt cache but didn't include that in the session log,
sorry about that, here's another way to reproduce (with the packages
referred by this same bug report):

  # apt-get install --reinstall gcc-4.7-base:i386 gcc-4.7-base:amd64
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 7 not upgraded.
  Need to get 284 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Get:1 http://ftp.debian.org/debian/ sid/main gcc-4.7-base amd64 4.7.1-7 [142 kB]
  Get:2 http://ftp.debian.org/debian/ sid/main gcc-4.7-base i386 4.7.1-7 [142 kB]
  Fetched 284 kB in 1s (180 kB/s)
  Apt pre-install-pkgs begin
  /var/cache/apt/archives/gcc-4.7-base_4.7.1-7_amd64.deb
  /var/cache/apt/archives/gcc-4.7-base_4.7.1-7_i386.deb
  Apt pre-install-pkgs end
  (Reading database ... 188680 files and directories currently installed.)
  Preparing to replace gcc-4.7-base:amd64 4.7.1-7 (using .../gcc-4.7-base_4.7.1-7_amd64.deb) ...
  Unpacking replacement gcc-4.7-base:amd64 ...
  Preparing to replace gcc-4.7-base:i386 4.7.1-7 (using .../gcc-4.7-base_4.7.1-7_i386.deb) ...
  Unpacking replacement gcc-4.7-base:i386 ...
  Setting up gcc-4.7-base:amd64 (4.7.1-7) ...
  Setting up gcc-4.7-base:i386 (4.7.1-7) ...

  # dpkg --unpack /var/cache/apt/archives/gcc-4.7-base_4.7.1-7_amd64.deb /var/cache/apt/archives/gcc-4.7-base_4.7.1-7_i386.deb
  (Reading database ... 188680 files and directories currently installed.)
  Preparing to replace gcc-4.7-base:amd64 4.7.1-7 (using .../gcc-4.7-base_4.7.1-7_amd64.deb) ...
  Unpacking replacement gcc-4.7-base:amd64 ...
  Preparing to replace gcc-4.7-base:i386 4.7.1-7 (using .../gcc-4.7-base_4.7.1-7_i386.deb) ...
  Unpacking replacement gcc-4.7-base:i386 ...

  # apt-get install -f
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
  2 not fully installed or removed.
  After this operation, 0 B of additional disk space will be used.
  E: Internal Error, No file name for gcc-4.7-base

  # dpkg --configure --pending
  Setting up gcc-4.7-base:amd64 (4.7.1-7) ...
  Setting up gcc-4.7-base:i386 (4.7.1-7) ...

The thing is that this only happens when two (or more?) instances are
involved, if there's only one then apt knows how to configure them
correctly.

> I will opportunistically close this bugreport with these two changes then,
> even through I couldn't reproduce either.
> (I am hopefully able to try a bit harder later today.)

Hope the new session helps you with this.

> The libpam-modules example above e.g. gives me a dpkg error on unpacking:
> 
> dpkg: error processing libpam-modules_1.1.3-7.1_amd64.deb (--unpack):
>  trying to overwrite shared '/etc/security/time.conf', which is
> different from other instances of package libpam-modules:amd64
> 
> i386 is unpacked, unpacking amd64 -- the other way around same error with
> a different file (/etc/security/limits.conf). I don't remember changing
> these files - noting that :i386 wasn't installed on my system previously.

Err, yeah sorry about that, I found about this apt bug while checking
a bug report for dpkg related to conffiles, so the above is currently
“expected”, I just didn't see afterwards because I have fixed it
locally on my dpkg and I'm still performing some testing, will be
included in dpk 1.16.9. :)

thanks,
guillem