Mike O'Connor <s...@debian.org> writes: > So the problem here is really that cedet, speedbar, eieio are now > implemented by emacs directly. These packages, which are no longer in > testing/unstable, should not have targetted emacs23. But since that > cat is already out of the bag, the easiest way to avoid this problem > in the future would probably be for emacs23 to conflict with these > older packages, which will help avoid this problem for people > upgrading from squeeze to wheezy.
> Therefore, I'm reassigning this bug from ecb to emacs23. I don't think that's the right answer, at least not by itself. People should be able to keep both emacs22 (with cedet) and emacs23 installed if they like. So I'd argue that the problem is that these add-on packages should either not have supported any version of emacs, even ones they'd never seen before, or they should have accommodated the possibility that any given unexpected emacs flavor might already include a version (as the gnus package does/did?), or they should do as described below. >From here, I'd suggest that the right way to proceed would be for new versions of these packages to be uploaded that only compile/install for emacs flavors < emacs23, and then I'll add a conflicts (<< WHATEVER) to emacs23* (and to emacs24 if it comes out soon enough to matter). 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
