Re: Using GNU's install-info in Debian instead of dpkg's install-info
I wanted to help with this, see the parallel thread at
http://lists.debian.org/debian-dpkg/2006/05/msg00063.html
but unfortunately I see it's moving in a different direction than I
intended. For everyone here, the main problem seem to be the Debian
vs. GNU fork. But for me, the main problem is the bugs. And as I see
it, while the merge might fix some of the particular bugs known right
now, the potential for many more remains, and eventually they'll come
charging back, because the algorithm is wrong.
It's wrong on two counts:
1/ The visual format of the dir file is used for collecting the sections.
This has all the robustness of, say, grepping for text in a Postscript file.
2/ Since no record is kept of the individual additions by packages,
there's no way to recreate the dir file from scratch. So, if a package
does screw up (often due to 1 above), all one can do is manually edit
the dirfile. This happens maddeningly often, at least to me:
see #367255, #367254, #367251.
There are two proper fixes. One is in the realm of policy: require
every info file passed to install-info to contain the full metadata,
including INFO-DIR-SECTION. Then we can dispense with the --section
option completely and 1 magically goes away, while 2 is solved by
rescanning the metadata in the top-level installed files (as Joey
suggests in the other thread).
The other way is to keep some kind of simple database on the side which
install-info first updates, then uses to generate the dirfile. dpkg is
a required package, so if install-info stays in dpkg the database library
must also be required. I thought of asking the Perl maintainer to move
the venerable Data::Dumper module into perl-base, that would be enough
for me.
--
A true pessimist won't be discouraged by a little success.
Reply to: