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 > <po...@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
