Bug#894159: transition: icu
On 23/04/18 21:19, László Böszörményi (GCS) wrote:
> 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.
Ok, I didn't realise that icu-le-hb was a separate source package.
>>> 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.
In that case I'm ok with removing icu-config, but please don't entangle that
with the SONAME bump. That is, reintroduce icu-config so we can have an easy
transition, and once the transition is finished, then you are free to drop
icu-config. Sounds good?
Cheers,
Emilio
Reply to: