>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> * Emacs: (emacs) . The extensible self-documenting text editor.
>> * Emacs-20: (emacs-20/emacs). The extensible self-documenting text editor.
>> * Emacs-21: (emacs-21/emacs). The extensible self-documenting text editor.
>> . update-alternatives is used to provide the default info file entries.
>>
>> Then each emacs version can have a modified into path. I am
>> not sure I really like this -- since C-C C-f leads to a different
>> location than just C-h i and Menu Emacs does.
Eli> The above will work, but only for bundled Info files. For example, if
Eli> you choose emacs-20/emacs, all the other Emacs-related manuals, such
Eli> as `message', `gnus', etc. will come from that directory. However,
Eli> what happens when the user installs a newer Gnus, downloaded from the
Eli> Gnus CVS? I expect that user to want to get that newer Gnus' manual
Eli> instead of the one which came with Emacs. Unless the user replaces
Eli> the manual supplied with Emacs with the newer version, the above
Eli> solution will not DTRT.
well. That is one way of doing it, and you have put your
finger on the flaw.
Alternately, if we settle on the solution of the emacsen
creating a separate sub directory for each version, BUT using update
alternatives to maintain a set of files in the top level info dir
that point to the files for the current default alternative; we can
have the best we solution we can offer under the circumstances.
The default would be, for most users, to just say info gnus or
info emacs; and that would lead one to $INFODIR/gnus, et. al. This
default file shall be a symbolic link managed by the alternatives
mechanism, so installing a new gnus shall do the right thing.
If you asked for a specific emacs version, and you then follow
the link to gnus there, I presume you are seeking information about
the bundled gnus.
However, unless something is done to C-h C-f, the information
provided would be for the default version.
If we have each emacsen re-order the Iinfo-path, then we shall
fail to see the info for indepndently installed packages, like
gnus. I don't like that.
For the majority of our installed base, the default emacsen
and the default, independtly installed emacs lisp packages should be
the most readi;y available, with no extra work by the user. Using sub
dirs and update-alternatives the problem has come down to extra work
to follow xrefs in non-default documentation.
Incidentally, the flavour of emacs lisp packaging for Debian
has been strongly influenced by th fact that majority of our target
installations are either personal desktops, where there are very few
(usually one) users, or they are server machines, which tend not to
have very many emacs lisp packages installed. So a number of
packagfes insert themselves automatically in the site-wide emacs
intialization process (this should give you a flavour of the type of
customization users tend to expect on a debian box).
>> I thik that C-h C-f should ask for a versioned emacs info file
Eli> If we agree on the subdirectory solution, C-h C-f will work, I think.
Eli> Please suggest a solution.
At the time of generation of files from teh texinfo files, one
needs to extract a version based string from there; and all files
produced have this version number embedded in them. An xref listing
should either be generic (look at the latest make insormation), or be
version stamped: look at the message file with this version number).
We then need a mechanism of updating the ``generic'', or
default, version of the info file (and we may need to do this only
for the top level info file for each package, since all files are
generated with version info embedded in them).
The model I am basing this on is the one used by shared
libraries on a UNIX system. We have patterns that deal with versioned
files, and simultaneous insallation of multiple versions of a shared
library using symbolic links and everything.
We would have to modify install-info to handle manipulation od
the symbolic links, like ldconfig does.
manoj
--
"You can't make a program without broken egos."
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
