Re: aspell upgrade woes
Steve Langasek <email@example.com> writes:
> On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
>> Reintroducing the libaspell15 could cause problems with
>> 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
>> 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
>> 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
> 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
> 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.
Society is never going to make any progress until we all learn to
pretend to like each other.