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

Re: Install-info transition, review time

Hi all,

after return from hardware-VAC and fixing grave texlive bugs and and and
here are now some remarks on the i-i transition.

On Di, 24 Mär 2009, Raphael Hertzog wrote:
> http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo
> Please review and raise any suggestions if you have any. There
> has been some extensive discussion on -dpkg already that you can read
> to understand the choices made:
> http://lists.debian.org/debian-dpkg/2009/03/msg00019.html

As mentioned, it would be nice to have that posted here, but
unfortunately the discussion and the transition plan are already sooo
long and I guess nobody will read it. The Wiki collects the most
important things.

On Do, 26 Mär 2009, Neil Williams wrote:
> * install-info operations will all then happen in triggers, not
> directly via maintainer scripts.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518737#12
> "The plan is always to get rid of install-info inside dpkg, so asking us
> for this change is not the right long-term solution. (And contrary to
> update-alternatives, I don't think such a change make sense)
> I would really suggest that you design a solution that doesn't require
> the postinst snippet at all. A simple solution could be:
> - have a package "install-info" register a file trigger
> on /usr/share/install-info/
> - have other packages provide a .install-info file in that directory
> that tells how install-info should be called
> - add a dh_installinfo helper to automatize the installation of this
> file
> - have info readers depend on the new install-info package

The experimental package of texinfo(source) I have prepared
	deb(-src) http:/people.debian.org/~preining/TeX/ i-i/
do it a bit differently by directly declaring interest on
/usr/share/info, and not adding another file layer.
That allows completion of all *current* postinst files calling
install-info. The wrapper in /usr/bin and /usr/sbin will just warn and
do nothing. That way packages will still work as they are now, the
/usr/share/info/dir file will be updated anyway using the new method,
and as soon as a new debhelper is uploaded the install-info calls will
disappear slowly from the maintainer scripts.

> Triggers will replace such maintainer script calls, making info
> documents no different to manpages in terms of their installation,
> hence no need for any support from Essential and triggers will simply
> not be called if install-info is not installed.

See above. Exactely that is the goal

> IIRC the remaining install-info script is to provide support until all
> the packages using maintainer scripts calls migrate to using triggers
> for their info documents.

	for maintainer scripts calling install-info with full path
	for maintainer scripts that still call install-info (not rebuild
	with new debhelper)
	and for doing the right thing when an admin calls it in the 
	intention to call GNU install-info

How do we proceed now with that? As said in a different email some weeks
ago, only ~50 of around 580 total info files fail when called with

There are some things some well experienced DD could take a look at:
- install-info binary package:
	. /usr/sbin/update-info-dir
	  a script I have written that recreates the dir file from all
	  the installed info files. Not very intelligent, but it does
	  its job. Review would be fine
	. /usr/bin/install-info
	  trivial script, the warning messages can be discussed
- dpkg binary package:
	. /usr/sbin/install-info 
	  a binary (C code) AFAIR to deduce the calling way, Raphael
	  can tell you were to get the code

Ok, hope that we get this going ...

Best wishes


Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
A pair of P.J.Proby's trousers.
			--- Douglas Adams, The Meaning of Liff

Reply to: