Re: aspell upgrade woes
Brian Nelson <pyro@debian.org> writes:
> 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.
Actualy, since aspell FTBFS and libaspell15c2 was never in the archive
for all archs there shouldn't be any package linked against it. The
transition rules said to wait before uploading rdepends. This
obviously needs to be checked.
Also, all sources should duild-depend on the new aspell or some buildd
will use the libaspell15c2 instead and still get the 'broken' depeneds
entry and delay removing libaspell15c2.
So I would say just drop libaspell15c and reupload anything that was
already wrongfully uploaded again.
> 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.
Why? This is exactly what a versioned conflict is for. The packages
have to be upgraded as pair and apt/dpkg will hapily do that. Having
libaspell15c2 conflict libaspell15 makes it no easier than having
libaspell15 conflict the old aspell-bin.
> I'm not sure what the best thing to do would be. I'm sort of inclined
> to just stick with the transitioned libaspell15c2...
Going back to libaspell unbreaks a bunch of rdepends and means aspell
can go into sarge on it's own, without waiting for the rats tail to
get transitioned as well. I think that is well worth it.
My 2 cents,
Goswin
Reply to: