> From: Manoj Srivastava <[EMAIL PROTECTED]> > 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.
