bug#9891: 24.0.90; Duplicated entry at the info directory

[Juri Linkov]

>> I think duplicate entries is not a problem.
>
> If they aren't, then why do we have Info-dir-remove-duplicates?

I meant that duplicate entries is not a problem when they lead to
different manuals.  IOW, when their absolute filenames are not duplicated.

> This is not specific to the situation with source and build
> directories.  This will happen any time you have identical entries
> collected from different DIR files, each one of them referring to a
> different copy/version of the same manual.  Info always searches for
> each file along Info-directory-list (INFOPATH for the stand-alone Info
> reader) in the order of the directories in that list, and displays the
> first matching manual it finds.  As long as this is the way it works,
> you will be unable to solve this problem.  It's like with searching
> exec-path for executable programs or load-path for Lisp libraries.

True, but this is what I see on GNU/Linux in "(dir) Top", at the top:

* Info: (info).                 How to use the documentation browsing system.

and in the "Texinfo documentation system" section:

* Info: (info).                 How to use the documentation browsing system.

The former is from the Emacs source tree, and the latter duplicate
is from /usr/share/info/.

> Even if you convert the file names in DIR entries to absolute form
> (which I think is wrong, see below), there are cross-references to
> other manuals inside each manual, which all use non-absolute file
> names; they are looked up using the same search order as described
> above.  That way lies madness.

I think it's more wrong when clicking on the link in the
"Texinfo documentation system" section visits the Info file
from the Emacs source tree instead of the Texinfo installation
in /usr/share/info/.

> Emacs does try to arrange Info-directory-list in the order that makes
> some sense when there are duplicates (see the doc strings of this and
> the related variables).  That logic should mostly work, but if it
> doesn't, I see no way around it except for the user to customize the
> list or to re-arrange her Info directories.

There is no problem with `Info-directory-list' where the
Emacs source location takes precedence over /usr/share/info/.
This is correct.

> Converting the file names into absolute ones means we diverge even
> more from the stand-alone Info reader, and effectively abandon any
> attempt to remove duplicate entries, instead _forcing_ the user to
> have duplicates.  I don't think this is a good idea, because the
> underlying problem is eventually that of the user or the sysadmin.

The problem with removing duplicates is its heuristics that is too
unpredictable and ad-hoc.  Sometimes it leaves duplicates not removed,
and sometimes removes non-duplicates, e.g. I see that it removed the
second entry from these lines in `dir':

* _exit: (libc)Termination Internals.
* _Exit: (libc)Termination Internals.