Karl> Hi Ian, (Did you bcc me? I doubt I am on debian-dpkg :) No, according to my records I To'd you :-)
Ian> For everyone here, the main problem seem to be the Debian vs. GNU Ian> fork. But for me, the main problem is the bugs. Karl> Well, resolving the fork will presumably only help with being able Karl> to then address the bugs to benefit the most people. Right. I have a hard time waiting for the merge to complete. Ian> require every info file passed to install-info to contain the full Ian> metadata, including INFO-DIR-SECTION. Karl> Sounds good, in theory. Karl> In practice, how many currently-installed info files lack Karl> INFO-DIR-SECTION? Good question, and easy to answer with a simple script, at least relative to the packages I have installed. I'll do that within a few days. Karl> What else do you think we should require? Everything necessary for the installation of a menu entry. I guess it's all within INFO-DIR-ENTRY, isn't it? Ian> The other way is to keep some kind of simple database on the side Ian> which install-info first updates Karl> Adding another database which has to be kept in sync (and which Karl> inevitably will go out of sync and then has to be recovered from) Karl> seems like more trouble to me, not less. The idea is that it wouldn't be "another" one, but _the_ authoritative one from which the visually formatted infodir file could always be re-derived. It wouldn't be visible to end users, and packages would interact with it through a narrow interface (ie. the revamped install-info). So the chance of it going somehow bad would be much, much smaller than with the visible dir file. Karl> Can you include bug-texinfo@gnu.org (and whatever on the Debian Karl> side) in future mail? Sure, and also including myself because Mail-Copies-To doesn't seem to be operative on the list. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]