Re: Support for multiple installed versions of a program.

[Manoj Srivastava]

>>"Eli" == Eli Zaretskii <address@hidden> writes:

 Eli> I think the interest is there.  IIRC, this was discussed about a year
 Eli> ago, perhaps even with you.

 Eli> My personal recollection from those past discussions is that the
 Eli> alternative I liked best was to make sure the list of the directories
 Eli> searched by the Info browser is such that it finds the right files
 Eli> first.  Perhaps that means we need to modify the search path as each
 Eli> manual is loaded into the browser, instead of initializing it only
 Eli> once.

        Hmm. I am not sure I understand.

        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. 

        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


        The add on packages themselves are responsible to see that
 they are included in the proper directory, since only they know which
 flavour/version they ought to be installed for.

        The info files in the add on directories may be duplicated if
 the add on package is install-able in more than one (but perhaps not
 all) flavours of emacs installed locally.
  
        How does all this interact with the top level dir file? 
======================================================================
The Directory File `dir'
------------------------

For Info to work, the `info' directory must contain a file that serves
as a top level directory for the Info system.  By convention, this file
is called `dir'. 
======================================================================

        Now, each dir file needs to be different for each emacs
 flavour+version (unless I am missing something). And in each such dir
 file, the new, add-on packages need to be inserted and removed from
 the top of the dir file, which makes browsing the top level file
 somewhat yucky. 

        Hmm. The top level dir in my current emacs seems to be
 organized in sections, alphabetically. So it would seem that in each
 section, we need a built in sub part and an add-on sub part, the
 add-on sub part coming first.

        Somehow, this does not seem cleaner than the emacs.d solution
 (though it is not any worse either).

        This, of course, still does not take into account multiple
 versions of an add on package coexisting.  


        Would be really nice if we could have Pterodactyl Gnus
 packaged for emacs20 and Oort Gnus  packaged for emacs21.  Thinking
 about that, I think I can see how I can manage the elisp  files for a
 Debian emacs-lisp package under the current policy, and the multiple
 directories approach would allow me to manage the info files as well.

        manoj
-- 
 Kids, the seven basic food groups are GUM, PUFF PASTRY, PIZZA,
 PESTICIDES, ANTIBIOTICS, NUTRA-SWEET and MILK DUDS!!
Manoj Srivastava   <address@hidden>  <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