>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> However, unless something is done to C-h C-f, the information
>> provided would be for the default version.
Eli> Not necessarily. All we need to make sure is that the Info reader
Eli> looks first in the same directory where the current Info file (the one
Eli> which you were browsing when you pressed C-h C-f) lives. The
Eli> stand-alone Info reader already does that, and I'm almost sure Emacs
Eli> does that as well (if not, it can be easily changed so it does).
Eli> If I'm right, then putting different versions into subdirectories will
Eli> not break C-h C-f, whether or not you use the default `emacs' file.
good.
>> If we have each emacsen re-order the Iinfo-path, then we shall
>> fail to see the info for indepndently installed packages, like
>> gnus.
Eli> Not necessarily. A package that is likely to be updated
Eli> asynchronously, even though it comes bundled, should adopt the
Eli> same version-related directory structure as Emacs. Thus, you
Eli> will have gnus-5.7/gnus, gnus-5.8/gnus, etc., and the default
Eli> `gnus' will point to one of them.
Hmm. This is more complicated than it appears at first thought.
a) It is hard to know a priori which package is likely to be updated
asynchronously. Gnus wasn't distributed separately for a long
time; and things like cc-mode or calc may appear as separate
packages in the future. Debian policy can't be quite this
ambiguous, unfortunately.
b) The only way this works is of we yank gnus out of the versioned
path of each emacs, and install it in its own versioned
directory. (else the version of gnus in the dir that is foremost
in the info path shall always be the one preferred by the info
rowser) That puts a burden on the emacs packaging, since emacs
comes with so many different info documents (and the versions of
each need to be tracked separately); this is a bit much for policy
to demand, unless there were a straigforward way to determine the
version of the program programmatically)
c) However, if we yank gnus out of the sdame directory, then you lose
the ability to simply go look for the information on the gnus that
came bundled in with emacs -- you now need to know version
numbers, since there is no gnus in the same directory, any xref to
Gnus shall lead you to the default version.
So xrefs to independently packaged programs are still a problem.
>> We would have to modify install-info to handle manipulation od
>> the symbolic links
Eli> I'd like to avoid using filesystem features such as symlinks, since
Eli> they are not portable outside Unix and GNU/Linux systems. We could
Eli> simulate symlinks via some new feature in the DIR file. We almost
Eli> have the infrastructure for that, in the indirect tag tables.
Umm. I am not conversant with theis mechanism. However,
wearing the hat of a debian developer, I can indeed use and exploit
symbolic links until a general solution is crafted.
manoj
--
I don't understand you anymore.
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
