Re: Support for multiple installed versions of a program.

[Eli Zaretskii]

> From: Manoj Srivastava <address@hidden>
> Date: Fri, 01 Feb 2002 04:15:30 -0600
> 
>         Let us see what kinds of scenarios exist for info files.
>  a) info files for packages contained within an emacs flavour/version.
>  b) An add on package that does not conflict with any built in
>     package, but may or may not be installed on all the
>     flavours/versions of emacs installed on the machine
>  c) An  add on package that does conflict with a built in package, but
>     is only installed on a subset of the emacs variants installed on
>     the machine. 

I agree with this classification.

>       The hard part is the info files provided by packages in
>  category c. If I understand your solution, it entails creating a
>  separate directory for each of these categories:
> 
>   emacs20/add-on
>   emacs20/builtin
> 
>   emacs21/add-on
>   emacs21/builtin
> 
>   xemacs20/add-on
>   xemacs20/builtin
> 
>   xemacs21/add-on
>   xemacs21/builtin

You must use different directories for different versions of the same
Info files, since otherwise the files will clash, as they all have
the same names (FOO.info-1, FOO.info-2, etc.).  So I think it goes
without saying that Info files for different versions of the same
package must live in different directories.

>       How does all this interact with the top level dir file? 

The DIR file is a separate problem, and IMHO it's a problem whose
solution can be found in a relatively easy way; see below for some
initial thoughts.

The reason I say that the DIR issue can be put aside for now is that
DIR's existence is not necessary for Info operation.  It's just a
convenient way of presenting to the users the list of manuals
installed on the system.

The _really_ hard problem, the one which we _must_ solve is that an
Info browser finds the right file when it is looking for a target of a
cross-reference or a menu entry.  That is, we must make sure that
"*Note: (foo)Bar::" gets to the right version of the file `foo', and
that "*Note: Foobar::" finds the subfile in the correct directory.  If
this doesn't work, Info will fall apart.  Those references don't go
through DIR, so what DIR look like is immaterial for this aspect.

Solving this problem for references inside a single manual is easy,
provided that we add some code that recomputes the search path for
Info files each time another manual is loaded, and stores that search
path locally with each manual's data structure (buffer in Emacs, a C
struct in the stand-alone reader, etc.).  By putting the directory of
the manual at the front of the search path, we can make sure the
browser will DTRT for that manual.

The plot thickens when you go outside the manual, especially if there
are interdependencies between them (i.e., references in the Oort Gnus
manual which refer to the Emacs manual should go to the Emacs 21
manual, not Emacs 20 manual).  I think if we have some information
recorded in the manual about the manuals it references, we could
solve this problem as well, by rearranging the search path in a
suitable manner.

A really hard and scary case is when the Info directories are set up
on the end-user system in a way that creates conflicts.  For example,
assume that manual A references manuals B and C, where B and C are
installed in different directories like this:

   directory foo has version 1 of B and version 2 of C

   directory bar has version 2 of B and version 1 of C

If our manual A needs versions 2 of both B and C, it's clear we
cannot solve that by merely arranging the search path.

However, I believe these problems can be solved by suitable hierarchy
of Info files.  Since Debian packages systems, it could actually make
sure those scary cases don't happen.

Does that plan make sense?

As for the DIR file: users don't actually see the DIR file as it
resides on disk.  What they see is the DIR _node_ which the Info
browser creates for them.  Currently, browsers typically concatenate
all the DIR files they find, in the order they find them.  But that's
not something carved in stone; we could easily change the code which
creates the DIR node so that it does whatever we want.  For example,
given some additional information, we could filter out the entries
that don't belong to the versions being used, or rearrange the
entries, or whatever.