> Date: Mon, 3 Aug 2015 23:32:08 +0100 > From: Gavin Smith <gavinsmith0...@gmail.com> > Cc: 793...@bugs.debian.org, Texinfo <bug-texi...@gnu.org>, > Rob Browning <r...@defaultvalue.org> > > If you don't care about being able to access renamed files via > cross-references, then the renaming of files to include versions is > good enough. If INFOPATH is the string "PATH", then the Info file > search path is deduced from the value of the PATH environmental > variable, so "info foo" should match the documentation for running > "foo".
Assuming you are alluding to what's currently in the code, this is only true for directories on PATH that have their own share/info subdirectories. Your text above could be interpreted to mean "info foo" will load foo-1.2.3.info when there's /usr/bin/foo-1.2.3 executable file found on PATH, but I don't see in the code anything that would make that happen. > Then there would only be one "foo.info" manual reachable for > each element in PATH (those other than the first can be accessed with > "info --all foo"). This means that "info foo" can only give the manual > for a particular version of foo if there is an executable called "foo" > somewhere in the PATH (assuming a sensible setup). Otherwise you'd > have to do "info foo-12.34" instead. This relegates that manual to a > second-class status, but that isn't too bad, because the corresponding > executable is also second-class when it comes to the shell finding it. This would make many "second-class" manuals, because there are actually many manuals that don't correspond to any executable. To name just a few, there are no executables named 'texinfo' or 'elisp' or 'coreutils' or 'gccint'. So adopting this path will just confuse users, because "info emacs" will magically work, while "info elisp" won't. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
