Your message dated Wed, 25 Feb 2015 13:01:25 +0100
with message-id <[email protected]>
and subject line Re: Bug#773062: dpkg fails to remove old packages because 
install-info needs dir file
has caused the Debian Bug report #773062,
regarding dpkg fails to remove old packages because install-info needs dir file
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
773062: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773062
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.16.15
Severity: important

Dear Maintainer,

This bug is related to #735159, and I ran into it during an attempted
upgrade to Jessie, but it concerns the version of dpkg in Wheezy
(1.16.15), not the one in Jessie (1.7.x). Also, the details are somewhat
different.

My system has been upgraded several times already, and has therefore
accumulated quite a few old packages which were left over from previous
Debian releases, among them gcc-4.1-doc.

During the upgrade to Jessie, apt-get complained that it couldn't
deinstall gcc-4.1-doc. 

Trying to remove just the single package resulted in the same error
message:

# apt-get remove gcc-4.1-doc
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  gcc-4.1-doc
0 upgraded, 0 newly installed, 1 to remove and 1066 not upgraded.
After this operation, 5,181 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 327691 files and directories currently installed.)
Removing gcc-4.1-doc ...
install-info: No dir file specified; try --help for more information.
dpkg: error processing gcc-4.1-doc (--remove):
 subprocess installed pre-removal script returned error exit status 1
Errors were encountered while processing:
 gcc-4.1-doc
E: Sub-process /usr/bin/dpkg returned an error code (1)

The problem is apparently that the prerm script in gcc-4.1-doc calls
install-info as:

install-info --quiet --remove /usr/share/info/gcc-4.1.info

But the version of install-info included in pkg-1,6,x requires an additional
parameter DIR-FILE, so prerm fails and the package is not removed.

I didn't find an option to force removal of the package.

(Editing /var/lib/dpkg/info/gcc-4.1-doc.prerm should work, of course)

I see two ways to fix this issue:

 * make install-info backwards-compatible by making the DIR-FILE
   parameter optional again.

 * Provide dpkg with an option to force removal of a package even if
   prerm fails. Like --force-remove-reinstreq this might result in parts
   of the package to remain on the system.


-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 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 dpkg depends on:
ii  libbz2-1.0   1.0.6-7+b2
ii  libc6        2.19-13
ii  liblzma5     5.1.1alpha+20120614-2+b3
ii  libselinux1  2.3-2
ii  tar          1.27.1-2+b1
ii  zlib1g       1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.0.9.4

-- no debconf information

--- End Message ---
--- Begin Message ---
Control: severity -1 normal

Hi!

On Sat, 2014-12-13 at 22:06:00 +0100, Peter J. Holzer wrote:
> Package: dpkg
> Version: 1.16.15
> Severity: important

> This bug is related to #735159, and I ran into it during an attempted
> upgrade to Jessie, but it concerns the version of dpkg in Wheezy
> (1.16.15), not the one in Jessie (1.7.x). Also, the details are somewhat
> different.

I'm afraid not much can be currently done from dpkg PoV, at least in
your specific case.

> My system has been upgraded several times already, and has therefore
> accumulated quite a few old packages which were left over from previous
> Debian releases, among them gcc-4.1-doc.
> 
> During the upgrade to Jessie, apt-get complained that it couldn't
> deinstall gcc-4.1-doc. 

Right, it should have been uninstalled earlier. And the bug you
reference earlier should make sure of that now.

> Trying to remove just the single package resulted in the same error
> message:
> 
> # apt-get remove gcc-4.1-doc
[…]
> Removing gcc-4.1-doc ...
> install-info: No dir file specified; try --help for more information.
> dpkg: error processing gcc-4.1-doc (--remove):
>  subprocess installed pre-removal script returned error exit status 1
> Errors were encountered while processing:
>  gcc-4.1-doc
> E: Sub-process /usr/bin/dpkg returned an error code (1)

> The problem is apparently that the prerm script in gcc-4.1-doc calls
> install-info as:
> 
> install-info --quiet --remove /usr/share/info/gcc-4.1.info
> 
> But the version of install-info included in pkg-1,6,x requires an additional
> parameter DIR-FILE, so prerm fails and the package is not removed.
> 
> I didn't find an option to force removal of the package.
> 
> (Editing /var/lib/dpkg/info/gcc-4.1-doc.prerm should work, of course)

> I see two ways to fix this issue:
> 
>  * make install-info backwards-compatible by making the DIR-FILE
>    parameter optional again.

It was backwards compatible in wheezy, but the wrapper (in the
install-info package) got switched to the native GNU version for
jessie. Also dpkg has not shipped its own wrapper for a long time
either.

>  * Provide dpkg with an option to force removal of a package even if
>    prerm fails. Like --force-remove-reinstreq this might result in parts
>    of the package to remain on the system.

There's already a bug report for that.

So given all the above, and considering this was an upgrade to an
unreleased Debian suite, which should do the right thing now that the
right Conflicts are in place, I think the best thing to do is to close
the bug report. Doing so now with this mail.

Thanks,
Guillem

--- End Message ---

Reply via email to