Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.
Rob Browning writes: > 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. After some investigation, I think we may be able to relax this policy and just require add-on packages to depend on emacsen-common, which is only ~150k, rather than some subset of flavors (which are all huge). I don't know if that would satisfy your concerns, but it doesn't seem too unreasonable to me, and I suspect it would eliminate the need for many of the foo-el packages. In any case, I'm planning to send an RFC to the debian-emacsen list shortly. > 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. Upon further consideration, it looks like this may be fine. I think that given the way that emacsen-common handles the installed-flavors file, the add-on packages shouldn't hear about a flavor until/unless it has finished its postinst call to emacs-install. Though I suppose strictly speaking, we might want to add a bit to policy that requires emacsen package maintainers to call emacs-install from a point in their postinst where the package should be considered completely ready to go. 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.
Josselin Mouette 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#586328: Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.
Julien Cristau writes: > emacsen-common is tiny and has no dependencies, so it doesn't seem that > big a burden. I believe that's not the core complaint. If I recall correctly, packages are required to depend on some combination of emacsen/emacsXY/xemacsXY, rather than emacsen-common itself. So that's a bigger burden unless you create a separate foo-el package. (See /usr/share/doc/debian-emacs-polcy.gz sections 5 and 6(D) etc.) 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.
Rob Browning writes: > As I've said before, while it might be possible to rework things to > remove the dependency, the original problem was complicated -- the > current arrangement wasn't chosen arbirarily. And in general, if you > want to use a compiled language, it's not unreasonable to expect some > infrastructure (perl, python, etc.). ...and of course perl and python aren't normally, compiled. I just meant that it's not unreasonable to expect language infrastructure. Though of course I'm sure it can be improved. -- 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.
On Sat, Jun 26, 2010 at 10:00:36 +0200, Josselin Mouette wrote: > 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. > emacsen-common is tiny and has no dependencies, so it doesn't seem that big a burden. Cheers, Julien signature.asc Description: Digital signature
Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.
Josselin Mouette writes: > severity 586328 serious > thanks > > Le vendredi 18 juin 2010 à 14:36 +0200, Ludovic Rousseau a écrit : >> Preparing to replace gtk-doc-tools 1.10-1 (using >> .../gtk-doc-tools_1.15-1_all.deb) ... >> ERROR: emacsen-common being used before being configured. >> ERROR: This is likely a bug in the gtk-doc-tools package, which needs to >> ERROR: add one of the appropriate dependencies. >> ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz >> ERROR: for details. > > 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. I believe you only need the dependency if you want to byte-compile code, and you can always create a separate, optional foo-el package. As I've said before, while it might be possible to rework things to remove the dependency, the original problem was complicated -- the current arrangement wasn't chosen arbirarily. And in general, if you want to use a compiled language, it's not unreasonable to expect some infrastructure (perl, python, etc.). 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.
severity 586328 serious thanks Le vendredi 18 juin 2010 à 14:36 +0200, Ludovic Rousseau a écrit : > Preparing to replace gtk-doc-tools 1.10-1 (using > .../gtk-doc-tools_1.15-1_all.deb) ... > ERROR: emacsen-common being used before being configured. > ERROR: This is likely a bug in the gtk-doc-tools package, which needs to > ERROR: add one of the appropriate dependencies. > ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz > ERROR: for details. 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. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
