On Mon, Apr 23, 2018 at 7:57 PM, Emilio Pozuelo Monfort <[email protected]> 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
