X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Date: Tue, 12 Mar 2002 08:28:49 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Peter J. Farley III" cc: djgpp-workers AT delorie DOT com Subject: Re: Simpler restructured dir.txi In-Reply-To: <3C8D941F.E96AD46E@dorsai.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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. > 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. > 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. 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.)