(please keep me in CCs) Hi, recently, gnucash broke here after a slib upgrade, because a catalog file has not been updated (see bug #75776 for details). What makes the situation complicated is, that the catalog belongs conceptually to another package (libguile6-slib), and there may be other catalogs installed belonging to other packages (e.g. guile1.4-slib) still. So the solution is not as easy as calling a "rebuild catalog" command from slib.postinst. This problem reminds me of the glibc nss woes recently discussed here, and it also seems to have a kin in the things we do with emacsen and packages containing elisp. All of these are generally: Package P depends on package D, and when package D is upgraded, some action (restart a service, rebuild a catalog, ...) needs to be taken by package P. As we have seen for libc, the simple solution that D simply does the action for all Ps is unworkable, because D's list of Ps will never by quite in sync with reality. What I have in mind is a general facility that all kind of packages can use if a situation like the above arises: * A Package P can register that it is interested in changes to packages D1, D2, ... Dn, which need not all be installed at the time. (junkbuster - a typical example of the nss problem - would register that it is interested in the fate of libc6. gnus would register for emacs20, xemacs20, xemacs21, even if only one is installed) * Once a package D changes state (it is upgraded, becomes installed, or removed), the "dep-change" script of all packages that registered their interests in D is called with appropriate parameters communicating the situation. (If libc6 goes from 2.1.95-1 to 2.1.96-1, "junkbuster.dep-change libc6 upgrade 2.1.95-1 2.1.96-1" will be called. Removal of xemacs20 induces the call of "gnus.dep-change xemacs20 remove". Installation of xemacs21: "gnus.dep-change xemacs21 install".) I think all of the current functionality of /usr/lib/emacsen-common/* could be mapped onto that scheme, like outlined above with gnus. Additionally, this should solve the nss mixup in a clean way (services simply restart themselves if glibc got upgraded). -- Robbe
Attachment:
signature.ng
Description: PGP signature