Rob Browning <[EMAIL PROTECTED]> writes: > These are the two best options, but I'm *really* hesitant to try and > guarantee that emacsen-common will work properly before it has been > configured. This means second-guessing the whole package > installation/dependency process and committing to some guarantees that > might make development (or redesign of emacsen policy) a lot harder > later on. > > How hard would it be for gettext to just provide a gettext-el package > and have that depend on emacsen as per policy? > > I may be over-concerned here, but trying to guarantee that a package > is functional before it's pre/postinst scripts have run seems like > asking for trouble.
However... that said, I went back and looked at the logs for bug 48681 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48681&repeatmerged=yes), and now I'm wondering if the fix suggested there might be sufficient. The suggested fix is to try and make sure that the emacsen-package-install script fully configures/initializes emacsen-common -- i.e. does the same things as the pre/postinst. Now that I've thought about it again, I'm beginning to feel like that might be OK -- any dissenting opinions? If this were in fact "safe", then we could think about changing debian-emacs-policy to fully eliminate the requirement that packages that have emacs components *depend* on emacsen, but instead they just check for /usr/lib/emacsen-common/emacs-package-install, and if found, run it. This is certainly more flexible, but I'm wondering if there are nasties that I'm overlooking. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
