Re: install-info: multiple INFO-DIR-SECTIONs
On Tue, Aug 15, 2006 at 04:55:28PM -0700, Micah J. Cowan wrote:
> (originally sent to firstname.lastname@example.org; I gather that didn't go through).
> I notice that Mike Stone's bug regarding GNU's "new" multiple
> dir-section format (#180127) has gone untouched for a very long time.
> In the meantime GNU has packages (at least coreutils, which spurred this
> bug in the first place) that use this format, and don't get properly
> installed into the info "dir", requiring the user to type "info
> coreutils ls", instead of the intended (and documented, via manpages)
> "info ls".
> I'd be interested in implementing a fix for this (note: I'm an Ubuntu
> user), but it would be a fairly major change (relative to the size of
> the script), and I don't want to do it in isolation only to have to redo
> a lot of the work.
> So I have some questions...
> - Should I work relative to the current unstable source packages, or
> is there a repository with more recent code?
The dpkg repository is:
(http://svn.debian.org/wsvn/dpkg to browse it)
> - Is there any existing test suite for install-make? That could help
> a lot: I'm liable to break something with an invasive change such as
I never seen any test suite for install-info
> - What other incompatibilities might exist between ginstall-make and
> install-make that I might need to be aware of?
> - Since GNU's install-make is fairly ubiquitous in the Free Software
> world, and the features between the two versions are very similar,
> why hasn't the original Debian version been replaced with the GNU
> version... is it that there are also features/subtle functionality
> differences in Debian's version that are needed?
Here are some pointers:
(and the whole thread in
(and the whole thread in
Two plans are described in these threads. One tries to move install-info
from dpkg to another package (probably a new package named install info
and built from the info source package). This new install-info would be
based on the GNU ones and will try to be compatible with the dpkg's one.
The second plan tries to replace install-info by a script which would
regenerate the info dir file based on all the .info files. (so this
feature needs to be added to a script or to the GNU's install-info, and
any packages that calls install-info in its maintainer scripts needs to
be changed to call this script or this new option)
A third plan which consist in implementing the missing features in the
dpkg's install-info was not (or hardly) mentionned. IMHO, it is not the
way to go.
In both cases, I think a transition will be needed (i.e. coordination with
dpkg, info, and maybe all the packages that provide info files). So in my
opinion, it is too late for Etch.
If ubuntu wants to spend some time on it, why not. The second plan is
probably a better idea: it will avoid future breackages of the info dir
file, but it needs a bigger coordination. The first plan is probably
easier to implement and deploy (I probably have an updated script if you