On Wed, Jan 18, 2012 at 19:53:16 -0600, Rob Browning wrote: > > 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). > That would be ok if we kept shipping those packages. But we don't, so there won't be a newer version...
Cheers, Julien
signature.asc
Description: Digital signature
