installation of emacs23 blocked by emacsen-common

Bug #623588 reported by William F. Hammond
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
emacsen-common (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: emacsen-common

Description: Ubuntu 10.04.1 LTS
Release: 10.04

This applies to a new desktop installation, rather than an upgrade,
via cdrom (made from iso downloaded 22 Aug 2010) of Ubuntu 10.04.1.

I have NOT seen this on two other machines where I upgraded to
Ubuntu 10.04 from earlier versions of Ubuntu (once from 8.04 and
once from 9.10).

Installation of the package "emacsen-common" will not complete because,
according to the message, at the configuration stage a call to
install-info is improper. (It is unclear to me why install-info should have been
called for "emacsen-common" installation.)

"aptitude" output is appended below.

-------------------------------------------------------------------------------------------------------------
Errors were encountered while processing:
 emacsen-common
 emacs23-common
 emacs23-bin-common
 emacs23
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up emacsen-common (1.4.19ubuntu1) ...
emacsen-common: Handling install of emacsen flavor emacs
install-info: No dir file specified; try --help for more information.
dpkg: error processing emacsen-common (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of emacs23-common:
 emacs23-common depends on emacsen-common (>= 1.4.10); however:
  Package emacsen-common is not configured yet.
dpkg: error processing emacs23-common (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of emacs23-bin-common:
 emacs23-bin-common depends on emacs23-common (= 23.1+1-4ubuntu7); however:
  Package emacs23-common is not configured yet.
dpkg: error processing emacs23-bin-common (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of emacs23:
 emacs23 depends on emacs23-bin-common (= 23.1+1-4ubuntu7); however:
  Package emacs23-bin-common is not configured yet.
dpkg: error processing emacs23 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 emacsen-common
 emacs23-common
 emacs23-bin-common
 emacs23
-------------------------------------------------------------------------------------------------------------

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: emacsen-common 1.4.19ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-24.41-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-24-generic i686
Architecture: i386
Date: Tue Aug 24 13:51:00 2010
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release i386 (20100816.1)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: emacsen-common

Revision history for this message
William F. Hammond (hammond) wrote :
Revision history for this message
era (era) wrote :

Could you please attach a copy of your /var/log/apt/term.log to this bug report? You will need sudo / root access to view or copy the file.

I am setting the Status of this bug report as Incomplete to mark that it is pending on further input from you. Please feel free to change it back to New once you have supplied the requested information. Thanks.

Changed in emacsen-common (Ubuntu):
status: New → Incomplete
Revision history for this message
William F. Hammond (hammond) wrote :

era, thanks for your reply; /var/log/apt/term.log is now attached

Changed in emacsen-common (Ubuntu):
status: Incomplete → New
Revision history for this message
William F. Hammond (hammond) wrote :

The call to install-info seems to be at the end of /var/lib/dpkg/info/emacsen-common.postinst:

      # Clean up dead emacs info entry...
      install-info --remove --quiet emacs

But now what is "install-info"?

      > type -a install-info
      install-info is /usr/local/bin/install-info
      install-info is /usr/sbin/install-info
      install-info is /usr/bin/install-info

      > /usr/local/bin/install-info --version
      install-info (GNU texinfo) 4.8
      >/usr/sbin/install-info --version
      install-info: warning: don't call programs like install-info with an absolute path,
      install-info: warning: /usr/sbin/install-info provided by dpkg is deprecated and will go away soon;
      install-info: warning: its replacement lives in /usr/bin/.
      This is not dpkg install-info anymore, but GNU install-info
      See the man page for ginstall-info for command line arguments
      install-info (GNU texinfo) 4.13

      /usr/bin/install-info --version
      This is not dpkg install-info anymore, but GNU install-info
      See the man page for ginstall-info for command line arguments
      install-info (GNU texinfo) 4.13

In the third case -- /usr/bin/install-info -- the command is a script that in this case
called /usr/bin/ginstall-info.

Notice that /usr/bin/install-info, the script, appears to do nothing when called with
--remove. It labels itself as a wrapper to GNU install-info designed to be compatible
with dpkg's install-info. So perhaps the postinst script should be calling this
script -- in which case no action would be taken because the argument is --remove.
But then it would appear that the call to install-info in the postinst script should be
removed.

Of course, the script front in /usr/bin is not seen since PATH consistently for
/usr/local, /usr, and / places sbin in front of bin.

How much of this package is cloned from debian?

Revision history for this message
era (era) wrote :

There is a long and convoluted history of problems introduced by install-info incompatibilities. dpkg used to ship its own version of install-info which was not plug-compatible with GNU's. That part I believe is now fixed but there are still many problems when dpkg expects a particular version of install-info. Perhaps dpkg should be hard-coded to remove /usr/local/bin from the PATH or something. Anyway, this is not a problem in Emacs per se. I'll see if I can find a correct open bug to mark this one as a duplicate of. Bug #476115 is tangentially related, and has pointers to several more or less pertinent reports. Googling for "install-info: No dir file specified; try --help for more information." also brings up a lot of bug reports for many different packages, in Debian, Ubuntu, and elsewhere.

> How much of this package is cloned from debian?

You mean emacsen-common? It's basically the same package, as you can see from the Changelog. http://changelogs.ubuntu.com/changelogs/pool/main/e/emacsen-common/emacsen-common_1.4.19ubuntu1/changelog

Revision history for this message
William F. Hammond (hammond) wrote :

Observations:

1. Hiding /usr/local/bin/install-info (which was the old GNU texinfo, v 4.8) enabled aptitude to finish cleanly.

2. Package management software operating in vendor (in this Ubuntu) territory, i.e., using the vendor's package database, should insulate itself from PATH components not under vendor control, e.g., /home/abigail/bin, /usr/local/sbin, and /usr/local/bin. Maybe, in fact, the distribution copy of root's .profile should explicitly set the PATH for root so that it does not depend on a default that may (or may not) be hard-wired into root's shell. (This, however, would not cover the case of package operations by a desktop installation's non-root administrative user.)

3. I first learned about info hypertext in 1989. By the early 1990's I was using GNU Texinfo's "install-info" on Suns. IMO this name should belong to GNU. Variants or fronts for package management should have different names, e.g., dpkg-install-info.

4. Is there justification for the complaint by /usr/sbin/install-info that it should not be called with a full pathname?

Revision history for this message
era (era) wrote :

The warning appears to be about the version in /usr/sbin being slated for removal from Debian / Ubuntu; any script using an explicit path will break when that happens. (Maybe it should suppress the warning if it's not being called from a script, though; but that seems like a very unimportant thing to fix during its limited remaining lifetime.)

Thanks for reporting back. I haven't been able to find a good dpkg bug to mark this one as a duplicate of, but I'm hesitant to reassign to dpkg because the problem is already well-known. Perhaps a new bug report should be opened to gather all these duplicates.

As for your other observations, I believe that your concerns are being addressed, although the transition is still in progress. http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo

Revision history for this message
William F. Hammond (hammond) wrote :

The duplicate status is correct. However it's the latest in a series, between ubuntu and debian, going back at least to 2008, of half a dozen or so duplicates.

Its' time to pay attention.

As I wrote in my comment of 8/28/2010 (above) there are two basic issues: (1) overuse of the name install-info, which properly belongs to texinfo, and (2) unwise PATH management when vendor package installation software is running.

Note that there are two variants of issue (1) according to whether texinfo is installed via dpkg or whether texinfo is installed outside of package management control in /usr/local or elsewhere such that its install-info appears near the front of the command path.

Thanks.

Revision history for this message
era (era) wrote :

There are other scenarios except texlive / texinfo. The problem is in dpkg and it is being addressed. My plan is to author a separate bug report against dpkg just so there is a convenient and understandable depot of information for users who report this problem. But for the time being, I took the liberty to mark this as a duplicate so it doesn't needlessly show up in bug listings for emacsen-common.

While I agree with your analysis of the issues, it is too late to change the unfortunate name overlap introduced by dpkg. However, this is being addressed, as dpkg moves to using GNU install-info instead. The suggested PATH manipulations are problematic, as there are situations where you do want local overrides in /usr/local/bin. Given that the first problem is being addressed, it's not obvious to me that the PATH issue needs separate attention.

Again, thanks for your bug report and problem analysis.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.