bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ian Zimmerman
Subject: Re: Using GNU's install-info in Debian instead of dpkg's install-info
Date: Fri, 26 May 2006 18:12:02 -0700 (PDT)
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

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.  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> If you want to require it for Debian, that's fine, of course, and
Karl> it can be an option or whatever in I-I.  I can imagine many people
Karl> would like it.  But, at least in the form I'm envisioning, I don't
Karl> think it should be the default for GNU.

Ian>     And it relects what Debian does for other things, like menus.

This should of course be "reflects", sorry for that.  I should really
learn to use the spellchecker :-(

Karl> Sorry, I don't know what menus you're referring to.

All of them.  Debian has a unified system for updating global menus
based on information in packages.  Window manager or desktop menus, HTML
documentation directories, others that I don't know of.  Each package
installs a little configuration file and, at post-install time,
regenerates the whole menu from all packages' bits (including its own).

Ian> The highlighted part is the catch - you're keeping the broken
Ian> parsing.

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.  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.

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.

(All things means different GNU cultural traditions, personalities, etc.)

-- 
A true pessimist won't be discouraged by a little success.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]