[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: aspell upgrade woes

Brian Nelson <pyro@debian.org> writes:

> Steve Langasek <vorlon@debian.org> writes:
>> On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
>>> 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.
> OK, very well then, I'll undo the GCC 4 transition for libaspell15.
> BTW, does anyone familiar with gettext want to send me a patch for RC
> bug #316666?  Upstream said he plans to make a new release with an
> upgrade to gettext 0.14.5 sometime this week, but I haven't heard
> anything else from him.

I just run gettextize, aclocal, automake (version 1.7 is needed irrc),
autoconf and recompiled. That seemed to have fixed it for me.


Reply to: