Re: info: INFOPATH interpretation severely flawed

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: address@hidden
> Bcc: address@hidden
> Date: Sun, 06 May 2012 20:06:43 +0200
> 
> Eli Zaretskii wrote:
> > > Apparently 'info' has used the information found in the 'dir' file of
> > > $dir1 (namely the reference to node "Invoking Automake") while using
> > > the .info file from $dir2.
> > 
> > Actually, all 'dir' files are concatenated into a single DIR node, and
> > only then used as a whole.
> 
> This is an implementation detail that leads to a bug.

Actually, this is documented behavior.  From the Texinfo manual:

                                The stand-alone Info reader merges
  an files named `dir' in any directory listed in the `INFOPATH'
  variable into a single menu presented to you in the node called
  `(dir)Top'.

Of course, this doesn't really help you.  In any case, I mentioned
this because of your "apparently ..." above, which assumed something
about how the Info reader processes the 'dir' files.  I thought I'd
tell how it actually works, for the record.

>   a) In this synthetic 'dir' file (which only exists in memory of 'info'
>      before it is presented to the user), remember which portion came
>      from which directory.
> 
>   b) When creating this synthetic 'dir' file, use absolute file names
>      of 'info' files everywhere, e.g.
> 
>        * Automake: 
> (/arch/x86-linux/gnu-inst-automake/1.11.2/share/info/automake).
>                            Making GNU standards-compliant Makefiles.
> 
>      and make 'info' understand these absolute file names.

This is doable, but is not free of disadvantages.  First, there's no
requirement that each directory on INFOPATH should have its own 'dir'
file.  Second, I think this will slow down Info startup, because it
will need to look for every Info file in every 'dir', to resolve its
full absolute file name.  On a typical system, there could be many
dozens if not hundreds of Info files.  By contrast, currently the Info
reader just parses the 'dir' files at startup.

But most importantly, this won't solve your original problem, I think:
you still cannot have several versions of the same manual FOO if all
the 'dir' entries say just "FOO", because the Info reader will always
pick up the first entry it finds.

So it's not an easy problem to fix.  I think some conventions in 'dir'
files for supporting such installations are inevitable.

> If I had had a tool which tells me
>     /arch/x86-linux/gnu-inst-automake/1.11.2/share/info/dir:41: reference
>     to automake.info node 'Invoking Automake' which does not exist in
>     /arch/x86-linux/gnu-inst-automake/1.12/share/info/automake.info
> everything would have been so easy.

I agree that such an "info-lint" would be useful.

> But sometimes it is not so easy: I have the problem also with
> INFOPATH=$dir2:$dir1 where dir2=/arch/x86-linux/gnu/share/info is under
> my control, whereas dir1=/usr/share/info is under 'root' control.
> So, in order to have INFOPATH=$dir2:$dir1 work, removing the conflict,
> I would have to modify $dir1/dir - which I cannot do without superuser
> privileges.

I think it's enough to modify only one of them, the one you can
control.

> > The Info readers are not prepared to cope with such calamity.
> > It is the job of whoever maintains the 'dir' files to
> > disambiguate entries there.
> 
> The one who maintains the 'dir' files is the 'install-info' program -
> from texinfo 4.13.

I meant the human who maintains the Info installations.  You can
invoke 'install-info' so as to override the 'dir' entries it creates.

> Your concept of "conflict" between two directories is flawed, because
> there is no way you could make 'install-info' not produce conflicts.

I think 'install-info' is an incomplete solution to a hard to solve
problem.

> It is simply a bug in the way the 'info' programs handles INFOPATH.

No, it's a flaw in the basic design of the Info system: it doesn't
cope well, to say the least, with several versions of the same manual
that are accessible from the same Info session.