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

possible ICU transition



The version of icu in debian is very old.  I have recently taken over
maintainership of the package.  I had originally intended to wait
until after the g++ transition had completed to do the ICU transition,
but I'm now strongly considering building new ICU packages to upload
to unstable before the g++ transition is finished.  The main reason
for this is that icu 2.1 fails to build on ARM, but icu 3.4 beta
succeeds.  The only direct reverse dependencies of the icu package are
the xerces packages which I also maintain.  There are only three or
four reverse dependencies of the xerces packages.  Right at this
moment, libxml-xerces-perl has succeeded on arm even though xerces25
has failed, which probably means that it is not in a stable state with
respect to the g++ transition.  Also, I'm about to move, go on
vacation, and change jobs, so my available time will drop for a short
time (from late August through mid September), and it might be good to
have this done before then.  There is also an icu28 package in debian,
but it is not necessary to convert its reverse dependencies to use the
new icu package at the same time -- that can wait until after the g++
transition.

If I start this transition as early as this weekend, it should not
hold up the g++ transition, and I will be able to monitor it closely
for two or three weeks before I start being much less available.
Given all this, can anyone think of any reason why I should not start
an ICU transition this weekend?

An alternative would to resolve the FTBFS on arm for icu 2.1 (which
worked before g++ 4.0) and to wait for xerces25 to rebuild and then to
do a binary NMU rebuild of libxml-xerces-perl

Thoughts?

--Jay

-- 
Jay Berkenbilt <qjb@debian.org>



Reply to: