multi-package aggregation of config, and install-info
A few things:
1. When I wrote install-info I wasn't aware of the existence of the
GNU one, and I think in fact that my one came before theirs. I had
seen install-info called from their makefiles, but assumed (since I
couldn't find it anywhere) that (a) they hadn't written it and (b) it
updated the dir file (since the actual copying was at least then done
by a different bit of the Makefile.in).
2. Regardless of how the situation came about we should try to get
eventually to doing the best thing, which is probably to make
install-info be the GNU one.
3. install-info is badly-designed. It should never have edited the
dir file in place - it should have kept a separate database directory,
preferably with one file per package. Therefore, we need to design
and implement a replacement with an incompatible interface, and we
should get all the maintainers to change to using that as and when it
is available.
4. install-info is not the only example of this. Many things, eg the
menu and install-mime mechanisms, have adopted install-info's broken
architecture. Sorry ! Nevertheless, we should fix them. I propose:
5. dpkg should have a mechanism whereby a package can declare hooks
to be executed when a particular directory is updated. I propose to
have two hooks:
One is executed every time a package has been unpacked (but before the
old version is removed) which touches a directory; it gets told which
files have been installed in that directory by the new package
(perhaps getting a list on stdin, perhaps as arguments), and it can
return exit statuses meaning `OK', `I am broken' and `the package
being installed is broken'. In the last case the installation will be
failed and dpkg will unwind back to the previous version.
The other script is exectuted at the end of many packages'
installations, and can do things like actually rebuilding `dir' files.
It can return `OK' or `I am broken'. `I am broken' in each case
causes the package with the hook script to be put into the
`half-configured' error state.
There will have to be an option for dpkg to maintain a list of which
packages which supply these `part files' are configured, so that (eg)
when an inetd package is upgraded the inetd.conf is updated both
before and after. Perhaps the package providing the hook should
specify a /var directory where dpkg would keep symlinks to the files
belonging to a configured package but none for the files belonging to
a not-configured one, and then run the second hook script whenever
that changed.
Then packages can rebuild files like /usr/info/dir and /etc/inetd.conf
from parts specified by the package maintainer, and the `dir
corrupted and noone can figure out why' type problems will not recur.
Ian.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: