Josselin Mouette <j...@debian.org> writes: > This is a serious WTF in emacsen-common and/or emacs itself. It’s not > appropriate to add a dependency on emacsen-common just for the sake of > including support for an editor. > > The bug (CCed) has been known for 8 years, so I’ll assume it won’t be > fixed and will simply drop emacs support from gtk-doc.
Just to be clear, as far as I know, this entire bug report is if anything a "wishlist" request. While it's almost certainly possible to change/improve our emacs policy, the current policy requires any package that wants to use the debian emacs infrastructure to depend on either emacsen, or on a specific set of emacs flavors, but not emacsen-common. And it's not about what any given bit in the emacsen-common scripts does or doesn't do. It's about the express guarantee, made by debian-emacs-policy, about when things will happen -- what will be configured when, that emacs23 will be fully configured before any add-on package scripts are called, etc. Changing those guarantees would require careful consideration of the potential effects on all of the existing add-on packages, and on the infrastructure itself. I'm not saying that can't be done, but rather that it's probably not as simple as "just change this one script to make it stop complaining". That said I'm beginning to wonder if there may actually be a different bug in the current system. I believe the original intent of the dependency policy may have been to ensure that the various flavors of emacs are fully configured before any given add-on's scripts are called. If that's right, then imagine an add on package foo that contains something like this: Depends: emacs23 | xemacs23 Presumably foo might try to byte compile itself for both flavors in its emacsen-common install script, but I believe dpkg could be within its rights to only configure emacs23 before trying to configure foo. Off the top of my head, I can't recall whether or not we considered that when drawing up the current policy. Much more generally, I've been wondering if a trigger based system might work better than the current approach, but I'm not all that familiar with triggers, so I've been reading up a bit. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
