On 5 August 2015 at 20:05, Eli Zaretskii <e...@gnu.org> wrote: > If the file is created as "-o foo-1.2.3.info", there should be no need > to rewrite anything, is there?
That's assuming the person installing the Info file is also creating it. Distributions of software products frequently distribute pre-built Info files, and I believe this is even mandated for GNU projects. > And I don't like to have to tell users "if you want to have severeal > versions of the same manual accessible, you must use --no-split", if > that can be avoided. Such conditions are always an annoyance and a > source of bugs. Acknowledged. Rewriting the indirect subfile table shouldn't be that hard. >> A similar problem is with image files associated with Info files. I >> can't think how that would be supported, but few Info files use images >> anyway. > > Why not use the same solution as with references between manuals? Yes, maybe. Rewriting image locations in Info files is possible, but feels a bit more problematic. The NUL BS [ sequence introducing a reference to an image file seems easy enough to search for though. I don't see any major obstacles in principle, although it's not a priority, at least for a first implementation. The same goes for symbolic links to directories containing image files for a manual. This old discussion could be worth reading: http://lists.gnu.org/archive/html/bug-texinfo/2009-12/msg00000.html >> You suggest having some kind of configuration file defining aliases >> for manuals. A subdirectory full of symbolic links is a kind of such a >> file, and not harder to update than any other kind of file format you >> could devise. > > Symlinks are less portable than init files. What operating systems don't support symlinks, and why is it important enough to add an extra feature for them that isn't needed on other operating systems, complicating the situation for everybody else who isn't using them? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
