Bug#894159: transition: icu
On Mon, Apr 23, 2018 at 7:57 PM, Emilio Pozuelo Monfort
<pochu@debian.org> wrote:
> First of all, sorry for the delay. I saw there were several issues here and
> decided to postpone this a bit.
Emilio! I already owe you a couple of beers. Hope we can meet again
in Hsinchu and have a chat about this.
> On 26/03/18 22:29, László Böszörményi (GCS) wrote:
>> It will need a quick bootstrap. It needs to build without the Layout
>> Engine API, then the support library (icu-le-hb). Only then ICU can be
>> built with the Layout Engine API as the two libraries tied together.
>
> Can you explain that? Why can't you enable Layout Engine from the start?
The Layout Engine was always buggy and was abandoned for a while. It
was removed in ICU 58.1 [1]. Actually it was deprecated with ICU 54.1,
released in October, 2014 (three and a half years ago).
Someone started to re-implement the API using an external library,
HarfBuzz[2]. But it is also stalled, the last real code commit is from
6th of May, 2016 [3]. Only one project still using it via the
Paragraph Layout and it's the OpenTTD game[4].
To answer your question, as you see Layout Engine is an external
project by now. It needs to build with the actual ICU ABI, which
changes with major releases (hence the need of a transition). When the
Layout Engine is available for the current ICU ABI, then the
additional Paragraph Layout API / libraries of ICU can be built. This
is the cause of the ICU build -> icu-le-hb -> ICU build again steps.
I might bundle the two sources together into one source package, but
then every ICU build would do this three step compilation instead of
one. It's enough to do once IMHO for every ICU major releases.
In short, I should speak with the OpenTTD folks how / why they use
Paragraph Layout API and if they can migrate to an other solution.
>> Some patches are simply adding '--with-icu=/usr' to the configure
>> invocation in debian/rules. Others are for ICU detection in the
>> configuration phase. No code change is needed in the packages.
>> If it matters, Ubuntu already transitioned with a bit different method.
>
> Are those changes and the large number of FTBFS because of the removal of
> icu-config? Can we keep it for now and file bugs at severity:important for the
> rdeps asking to fix the build when icu-config is removed? That should ease this
> transition.
Agree, keeping icu-config would help a lot with the transition.
Ubuntu did the transition this way. On the other hand, icu-config is a
simple script and don't know much about MultiArch and/or
cross-compilation. Upstream has pkg-config files for a while, but not
all dependent packages migrated to it yet. :-/
OK, riscv64 already over the initial bootstrap and rebuild steps.
> I would appreciate a number of failing rdeps and how many are due to ICU API
> changes and how many are due to icu-config removal.
As I remember, 99% of the FTBFS reasons were the icu-config removal,
others are the dependent package bugs I've already mentioned. I do not
recall any API change. In short, there are fifteen packages FTBFS and
all is due to the icu-config removal. This is true for the date of my
previous mail. There were several dependent packages upload since
then, but I think the situation remained the same.
Cheers,
Laszlo/GCS
Reply to: