Joey Hess <[EMAIL PROTECTED]> writes: > See bug #268466 for background
I'm not sure it's directly relevant to your immediate problem, but after skimming through the bug, I wanted to note that currently it is *not* OK according to policy for add-on packages to depend on emacsen-common alone. As debian-emacs-policy.gz mentions, add-on packages that need to use the emacsen-common infrastructure must depend on whatever combination of emacs packages they're suitable for, i.e. emacs21 | xemacs20, or perhaps just "emacsen" if they're not version specific. Of course it's still OK for add-on packages to have an *additional* dependency on emacsen-common if they need to make sure that some specific version of the infrastructure is available (see the fboundp example). Currently, if the maintainer doesn't want to have the main package depend on any emacsen, but they do need to use emacsen-common infrastructure (i.e. they have files that actually need to be byte compiled rather than just interpreted) the only solution (and the correct solution) is to break the package up into two sub-packages, i.e. gettext and gettext-el. Though it would be nice to allow one package to optionally and opportunistically use the infrastructure depending on whether or not the user already has any emacsen installed, we didn't come up with an approach that would allow that and still satisfy all of the other criteria we wanted when we were devising the current policy. (If/when dpkg adds some of the package installation related hooks that I have seen discussed, adding such functionality might become much easier, though I'll have to refresh myself on what might be possible.) I'd like to make it clear that I'm not saying that the emacsen-common infrastructure can't be improved, just that some improvements may be difficult (or maybe impossible) without other changes to debian infrastructure. I can't comment conclusively without reviewing policy, the emacsen-common scripts, and dpkg's current facilities with some care. > -- I need a way for a package's postinst script to check to see > whether emacsen-common is configured and ready for > /usr/lib/emacsen-common/emacs-package-install to run. The patch > proposes checking for /var/lib/emacsen-common/installed-flavors, but > it's not clear to me if this file is intended to be checked for by > packages that use emacsen-common, or is purely internal and might be > renamed tomorrow. Breaking all postinst scripts that use it. What > should I do? Right now, there isn't any defined way to check whether or not emacsen-common is installed. Current policy and emacsen-common behavior has been set up to make sure that if an add-on package depends on the relevant set of emacsen, then these emacsen will all depend on emacsen-common, and the "right thing will happen" at package install/removal time, and there won't be any race conditions. If we want to make changes, we'll need to review/revise policy. I'm not opposed to that, but I'd like to be very careful. Back when we devised the current policy, I wanted a more flexible arrangement too, but the install-time details and corner cases really did substantially constrain the set of correct solutions. Perhaps that has changed since. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
