Re: Using GNU's install-info in Debian instead of dpkg's install-info

[Eli Zaretskii]

> From: Ian Zimmerman <address@hidden>
> Date: Fri, 26 May 2006 18:12:02 -0700 (PDT)
> Cc: address@hidden, address@hidden, address@hidden
> 
> 
> Karl> I wouldn't expect resource consumption to be the problem.  The
> Karl> problem I see is breaking a new install of package X because of
> Karl> something that has happened with package Y or some administrator's
> Karl> action, possibly many years ago.  Requiring this sort of perfect
> Karl> consistency of the past to install a package in the present seems
> Karl> fundamentally wrong to me, and a frustration for users and
> Karl> administrators, not a help.
> 
> What consintency is required?  As far as I can see, packages' info files
> are completely independent.

They are _almost_ independent.  The small amount of dependency stems
from the fact that each Info file specifies the section where it wants
to live in DIR.

> In fact it is the _present_ way that poses this problem, if package
> X screws up the dirfile format, Y will not find its section
> correctly (not that it won't happen for other reasons, as I tried to
> explain before).

Karl suggested to make this regeneration of the whole DIR menu as an
optional behavior.  Wouldn't this let us have the cake and eat it,
too?

> Karl> I don't understand.  An info file says to install itself in
> Karl> section XYZ.  So install-info installs it in section XYZ.  What's
> Karl> broken about that?  And what name can be used besides the one the
> Karl> info file says, anyway?
> 
> How do you __find__ the section in the dirfile?  You must use some awful
> regular expression search to find the spot, which is prone to false
> positives and false negatives.  And then you must cut up the dirfile and
> paste the new bit in.

The code doesn't use any regular expressions, it uses exact text
comparison (strcmp and the like).  It also doesn't cut or paste the
file.  Please take a look at the code.

In a nutshell, the program reads the entire DIR file into memory,
builds the data structure that reflects what's in the menu (i.e. all
the sections and the menu items found in each section), then sorts each
section alphabetically and adds the new entries in the right place in
each section specified in the Info file or the command line.  Then it
produces a new DIR file from the data structure built in memory.

> All of the bugs that I mention, that motivate me
> in this debate, and that would motivate me to work on an implementation,
> spring from this broken process.  There are _many many many_.  Really.
> I cited three I had to report 2 weeks ago or so.  I had reported 2 or
> 3 other before.  And there were many I didn't even bother to report,
> preferring like you to hand edit the file in impotent rage.

Well, maybe we should see a sample of those bugs to decide how big is
the problem and how radical should the solution be.  It's possible, at
least in theory, that those bugs are relevant only to the way the
Debian version of install-info works, and don't happen with the GNU
version.  Then again, they might be common bugs.

> Karl> Anyway, I really hope Debian I-I and GNU I-I can be merged in the
> Karl> ways Norbert was originally proposing (are you even seeing this
> Karl> mail any more, Norbert?), even if the whole world can't be fixed
> Karl> at the same time.
> 
> You see, this is why I was disappointed when the discussion turned in
> the direction of the merge; I sensed (earlier than most people in the
> thread, I think) that the unification goal and the fixing goal are, all
> things considered, incompatible.

FWIW, I don't see any show-stoppers for now, nothing that a bunch of
options cannot resolve.  If we have options that leave everybody
happy, we should be able to merge, don't you think?