Re: aspell upgrade woes
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...
--
Society is never going to make any progress until we all learn to
pretend to like each other.
Reply to: