Mail Archives: djgpp-workers/2002/03/12/22:21:48
At 08:28 AM 3/12/02 +0200, Eli Zaretskii wrote:
>On Tue, 12 Mar 2002, Peter J. Farley III wrote:
>
>> As Eli requested, I created a new DIR file using makeinfo and my
>> candidate dir.txi, and then ran the following install-info
commands,
>> all while in the DJGPP info directory:
>>
>> install-info textutils.info
>> install-info automake.info
>> install-info autoconf.info
>
>Thanks.
>
>> As I thought, the result is not pretty.
>
>Actually, it's not that bad. I feared it would be worse.
Well, It *does* severely affect the structure I built, but I guess
that's to be expected.
>> I believe that any package whose texinfo file uses only "@format"
and
>> "START-INFO-DIR-ENTRY" will have all of its entries sorted by name
>> into the "Miscellaneous" section.
>
>That's true, assuming you don't use any command-line options of
>install-info to tell it otherwise.
>
>> Similarly, any package that uses
>> "@dircategory" and "@direntry" will create or add to those named
>> sections, again at the end of the DIR file.
>
>No, the ``end of DIR'' part is inaccurate: if there's already
a >category in DIR with an identical name, install-info should put the
>entries in that category, not at the end. At least, that's my
>recollection from the last time I looked at the code.
I did try to indicate that when I said "...or add". Unfortunately, I
haven't yet found two GNU packages that use @dircategory and also use
the same @dircategory value -- at least not among the current DJGPP
ports.
>> The only solutions to the problem that I can see would be to (a)
>submit
>> patches to bring the GNU source into line with DJGPP's categories,
or
>> (b) to disable DJGPP's install-info or rename it so that it must be
>> manually invoked if the user really, really wants to run it. With
>> instructions on how to enable or un-rename it if that is what they
>wish
>> to do.
>
>There's another solution: an option could be added to install-info
not
>to remove the existing entries. This will still add new entries, but
>the old ones will remain intact.
That would help, but possibly better would be to detect existing
entries and ask the user which one to keep, or an option that do the
same thing -- i.e., an option that says "if you find a duplicate entry,
keep the one that's already there and toss the new one", and it's
opposite of course "if you find a duplicate, *replace* it with the new
one, ignoring the embedded @dircategory value.
>Of course, if zippo supports the necessary feature, and users start
>using zippo to install packages, the problem will become less
grave.
>(Not that it's grave now, IMHO, since most users don't even know
about
>install-info, and our DIR is reasonable up-to-date most of the time.)
Pardon my confusion, but what do you mean by "necessary options"? Not
to automatically run install-info, as Rich has recently put into zippo
0.1.6?
---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org)
- Raw text -