[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: info.info document texinfo vs emacs



Norbert Preining <norbert@preining.info> writes:

> Hi Rob, hi all Emacs maintainers,
>
> the upcoming texinfo 6.1 will remove the info.texi/info.info 
> as it is now distributed by emacs.
>
> I am planning to simply drop the info.info file in /usr/share/info
> in the upload of texinfo 6.1, but wanted to ask your opinion concerning
> this move, as well as your plans concerning info.info.
>
> We also should somehow work out how the emacs-NN/ subdirs should be
> handled at some point.

Ahh, right.  So I recently posted this to a bug-texinfo thread, and to
our our bug tracker:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+793067#230

  ...but here's what I'm currently contemplating for at least Debian
  Emacs and Guile, and I wondered if it seems plausible given the
  current tools:

    - Put all of an Emacs version's info pages in /usr/share/info/emacs-XY
      as we do now, but stop trying to mangle the dir entries (or anything
      else for that matter).

    - Have Emacs continue to add its version-specific info dir
      (/usr/share/info/emacs-XY) to the front of the info path so that if
      invoked directly, /usr/bin/emacs-XY will prefer its own pages by
      default.

    - Manage /usr/share/info/emacs.info.gz via Debian's
      update-alternatives (with all the other related files as --slave
      pages: i.e. emacs.info-*, calc, org, etc.).  This should allow the
      standalone reader (and anything else) to find the system preferred
      info pages by default.

    - Document that if you have multiple versions installed, and you want
      to read the pages for an alternative that's not the default with the
      standalone reader, you can use "info -d /usr/share/info/emacs-XY
      ...".  For Emacs you'd need to prepend to the Info-directory-list.

  The main change is the use of update-alternatives which should make the
  Debian info arrangement look substantially less unusual.  (This approach
  does depend on update-alternatives handling sets reasonably whose
  --slave link sets differ - which I need to double-check.)

Happy to hear if that sounds plausible, or what might be preferable.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


Reply to: