On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote: > Steve Langasek <vorlon@debian.org> writes: > > On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote: > >> It's a C++ library and the ABI changed due to being compiled with GCC > >> 4.0. > >> [Actually, although it's written in C++, AFAIK it only exports a C > >> interface so the transition may not have been necessary. I only > >> realized this yesterday though and I'm not entirely sure a > >> non-transition would be safe.] > > Heh. I've just confirmed this... > > As with libGLU, libaspell is used in enough places that there's a > > definite benefit to not breaking package compatibility unnecessarily. > > Since libaspell15c2's shlibs refer to "libaspell15c2 (>= 0.60)", the > > only way to provide full compatibility is with two real packages. I > > would suggest restoring libaspell15, and creating a dummy > > libaspell15c2 package that depends on libaspell15 and can be dropped > > once everything has been rebuilt to use libaspell15 again; that would > > minimize the disruption caused by the flip-flopping of the lib name. > > Brian, if you agree, I'm happy to prepare a patch. > Reintroducing the libaspell15 could cause problems with /usr/bin/aspell, > since it actually goes outside the C API of libaspell and uses C++ > linkage to some symbols. I "fixed" this bug (#307481) by making > aspell-bin (or now just aspell) depend on the Source-Version of > libaspell. > However, that fix is not in the stable package of aspell. In stable, > aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade > of just libaspell15 would break aspell-bin. I suppose I could make the > new libaspell15 conflict with the old aspell-bin, but that's rather > clumsy and could make upgrades even more awkward. > I'm not sure what the best thing to do would be. I'm sort of inclined > to just stick with the transitioned libaspell15c2... Well, using libaspell15c2 will definitely cause some complexity on the upgrade path from sarge to etch. I don't know how much having libaspell15 conflict with aspell-bin (<< $version) would do so. I suspect that it would be substantially less since there are only four packages in sarge which depend directly on aspell-bin or aspell, vs. 61 packages which depend on libaspell15 -- at a minimum, the worst-case scenario when conflicting with aspell-bin (<< $version) looks substantially better. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature