Re: possible ICU transition
I've uploaded ICU 3.4. Once it clears new, people who depend upon
icu28 or embed icu in their packages can try it. Read on if you care
about ICU.
Steve Langasek <vorlon@debian.org> wrote:
>> Given all this, can anyone think of any reason why I should not start
>> an ICU transition this weekend?
>
> If the only packages that need to be rebuilt for this change are xerces25
> and xerces26, and those packages don't also need to have name changes in the
> process, then I see no reason not to proceed with the change. You'll have
> to upload icu one way or another to fix the FTBFS, so you might as well go
> with the lib transition while you're at it since the set of affected
> packages is so small.
I uploaded ICU 3.4 yesterday with a significantly simplified packaging
based on reading about changes to the library since 2.1 and looking at
the packaging section of the upstream manual. When it clears NEW and
finishes building on all architectures, I'll re-upload xerces25 and
xerces26 packages rebuilt with the new ICU. I've also reorganized
those packages to create only an ICU version of the library. (Rather
than libxerces26c2 and libxercesicu26c2 both existing, now only
libxerces26c2 exists, but it replaces, provides, and conflicts with
libxercesicu26c2 to avoid any breakage and smooth upgrade path -- I've
tested multiple scenarios.) With the new ICU packaging, it is no
longer necessary to load extra packages outside of the xerces
packages' own dependencies to get fully working locale support,
hopefully resolving this category of bugs once and for all. If my
understanding is correct and I haven't made any mistakes, xerces's
reverse dependencies should be unimpacted and probably don't even need
to be rebuilt. I tested some of my own applications with the new
xerces libraries, and they worked fine both with and without
recompilation. (I had discussed this xerces reorganization many
months ago on debian-devel, or at least on IRC, and decided to wait
until this ICU transition.)
The new ICU packages keep locale data in a shared library (which is
the library default). This creates a bit of a larger
architecture-dependent package, but parts of the
architecture-independent parts of 3.4 are byte-order dependent anyway,
and the new packaging is much simpler and should be more robust.
Besides, based on popularity contest, no one is really using the
features of the old packaging that would allow certain very advanced
customizations to be made after installation. It's also worth noting
that blade's icu28 packages use the shared-library data packaging
method as well, and no issues related to that have been raised.
--
Jay Berkenbilt <qjb@debian.org>
Reply to: