Bernd Eckenfels wrote: > b) I wanted to have a list of all quetions and thought the editor frontend > is the way to go, but I was wrong, since it generates separate fiels for > each package. Would it be possible to generate one large file for all > configured packages. The frontend will present one file for each block of questions. The debconf protocol does not allow it to do any more consolidation than that. > c) for various packages I get warnings like: > Posibly corrupt data, adding question xxxx (sorry no cut+paste) > (I must admit this is a pretty old system, but I cant think of any file > system corruption. Could this possibly be that some questions where not > added during updates or that old debconf versions had errros, here?) This is a workaround for past debconf db corruption issues which I could not track down for the past year or so. > d) a lot of packages where calling updates-menu (even install-docs) on > configure action which slowed this reconfigure process very much down. I > wonder if we can change policy/menudoc to say that packages to not need to > call update-menu on configure if the menu entries do not depend on debconf > configuration options. Another option would be to lock the dpkg status area > while runnung reconfigure, because this will delay the update-mneus action > into an _single_ background process (if I understand its function right) at > the end of the run. While postinst scripts can look at the DEBCONF_RECONFIGURE environment variable, that is a hack and there is no way to do it right unless and until $1 = reconfigure gets into policy. At best this should only allow for optimizations anyway. Is stuff reconfigured so often? It would probably be more productive to optimize menu, which should be able to run 10 to 100 times faster than it currently does through smart use of caching -- I hope Chris's rewrite will be a lot better. > e) it looks like reconfigure is calling prerm and prerm is not checking for > configure, which is for example a problem with emacs20: > --- > emacs-remove emacs20 > emacsen-common: Handling removal of emacsen flavor emacs20 > emacsen-common: purging byte-compiled files for emacs20 > remove/gettext: Purging byte-compiled files for emacs20 > emacs-install emacs20 > install/gettext: Byte-compiling for emacs20 > Wrote /usr/share/emacs20/site-lisp/gettext/po-mode.elc > Done > emacsen-common: Handling install of emacsen flavor emacs20 > emacsen-common: byte-compiling for emacs20 > ... > --- I don't know if this is a bug in emacs20 or not -- the prerm gets $1 = upgrade, and perhaps it needs to do this on upgrade. -- see shy jo
Attachment:
pgpn9IUNP9FWt.pgp
Description: PGP signature