Bug#898571: build dependency cycle between icu and icu-le-hb

2018-11-17 Thread Matthijs Kooijman
Hi folks,

I just uploaded openttd 1.8.0-2, which no longer has the ICU layout API
enabled. This should clear the way for dropping iculx and icu-le-hb.

This change makes at least Arabic and Hebrew support in OpenTTD pretty
much unusable. However, some additional investigation suggests that
Harfbuzz and ICU should provide enough building blocks to implement
something better again. See upstream github for discussion about that:

https://github.com/OpenTTD/OpenTTD/issues/6922

Gr.

Matthijs


signature.asc
Description: PGP signature


Bug#898571: build dependency cycle between icu and icu-le-hb

2018-11-16 Thread GCS
Hi Matthijs,

On Thu, Nov 15, 2018 at 11:19 PM Matthijs Kooijman  wrote:
> > I do Cc its maintainer Matthijs and if he acknowledges I will drop
> > libiculx and icu-le-hb altogether.
>
> Yeah, I think that dropping icu-le-hb is the best course forward. I want
> to doublecheck that that does not have any unintended side effects. Ok
> if I get back to you about this in 2/3 weeks? Or would you rather act on
> this before then?
 I think 2/3 weeks is fine to wait for your checks - of course if you
can share what to test then I'd like to help to speed up the testing
process.
On the other hand, please fix #913509 [1] soon.

Cheers,
Laszlo/GCS
[1] https://bugs.debian.org/913509



Bug#898571: build dependency cycle between icu and icu-le-hb

2018-11-15 Thread Matthijs Kooijman
Hi Laszlo,

> I do Cc its maintainer Matthijs and if he acknowledges I will drop
> libiculx and icu-le-hb altogether.

Yeah, I think that dropping icu-le-hb is the best course forward. I want
to doublecheck that that does not have any unintended side effects. Ok
if I get back to you about this in 2/3 weeks? Or would you rather act on
this before then?

Gr.

Matthijs


signature.asc
Description: PGP signature


Bug#898571: build dependency cycle between icu and icu-le-hb

2018-11-15 Thread GCS
Hi,

On Wed, Nov 14, 2018 at 6:42 AM Helmut Grohne  wrote:
> On Sun, May 13, 2018 at 07:52:14PM +0200, Helmut Grohne wrote:
> > icu introduces a build dependency cycle with icu-le-hb. Doing so breaks
> > architecture bootstrap. The full cycle is:
> >
> > src:icu Build-Depends: libicu-le-hb-dev
> > libicu-le-hb-dev is built from src:icu-le-hb
> > src:icu-le-hb Build-Depends: libicu-dev
> > libicu-dev is built from src:icu
>
> This exact dependency cycle is present in icu/63.1-4.
 Thanks for caring these, much appreciated.

> > An alternative may be splitting icu-lx into separate binary packages
> > libiculx60 and libicu-lx-dev. Then we could add a build profile
> > pkg.icu.nolayoutex to skip generating these packages. Downstream users
> > would have to add an explicit dependency on libicu-lx-dev to get that
> > functionality.
 This can be a solution, but I'm still would like to get the long
deprecated (and no longer part of upstream) layout library removed.
Especially that the third party addition to extend its support is dead
as well.

> I see that you added libiculx63, but there is no libicu-lx-dev. At this
> point, we could make the build dependency from icu on libicu-le-hb-dev
> optional. That would remove libiculx63, but it would also remove
> libicu-dev. Therefore the cycle is still fully present. In order to
> break it, the -dev package must be split as well. Whatever
> src:icu-le-hb-dev build depends on (presently libicu-dev) must not
> depend on libiculx63. That's why I originally proposed "libicu-lx-dev".
 I'd like to drop icu-le-hb instead. The only package still needs
paragraph layout is openttd. Its upstream said Debian should drop its
use[1] immediately.
I do Cc its maintainer Matthijs and if he acknowledges I will drop
libiculx and icu-le-hb altogether.

Regards,
Laszlo/GCS
[1] https://github.com/OpenTTD/OpenTTD/issues/6922#issuecomment-427666586



Bug#898571: build dependency cycle between icu and icu-le-hb

2018-11-13 Thread Helmut Grohne
Control: reopen -1
Control: found -1 icu/63.1-4

On Sun, May 13, 2018 at 07:52:14PM +0200, Helmut Grohne wrote:
> icu introduces a build dependency cycle with icu-le-hb. Doing so breaks
> architecture bootstrap. The full cycle is:
> 
> src:icu Build-Depends: libicu-le-hb-dev
> libicu-le-hb-dev is built from src:icu-le-hb
> src:icu-le-hb Build-Depends: libicu-dev
> libicu-dev is built from src:icu

This exact dependency cycle is present in icu/63.1-4.

> An alternative may be splitting icu-lx into separate binary packages
> libiculx60 and libicu-lx-dev. Then we could add a build profile
> pkg.icu.nolayoutex to skip generating these packages. Downstream users
> would have to add an explicit dependency on libicu-lx-dev to get that
> functionality.

I see that you added libiculx63, but there is no libicu-lx-dev. At this
point, we could make the build dependency from icu on libicu-le-hb-dev
optional. That would remove libiculx63, but it would also remove
libicu-dev. Therefore the cycle is still fully present. In order to
break it, the -dev package must be split as well. Whatever
src:icu-le-hb-dev build depends on (presently libicu-dev) must not
depend on libiculx63. That's why I originally proposed "libicu-lx-dev".

Helmut



Bug#898571: build dependency cycle between icu and icu-le-hb

2018-05-13 Thread GCS
On Sun, May 13, 2018 at 7:54 PM Helmut Grohne  wrote:
> icu introduces a build dependency cycle with icu-le-hb. Doing so breaks
> architecture bootstrap. The full cycle is:
[...]
> I haven't fully understood the reason of the new dependency yet, so I
> cannot easily suggest a cure. One thing that strikes me as odd is that
> these source packages seem to be fully interdependent. That suggests
> that merging them into a single multi-tarball source package might work.
  Yes, this might work.

> Reading http://userguide.icu-project.org/layoutengine/paragraph suggests
> that doing so may be impossible, because that'd require adding harfbuzz
> to icu's Build-Depends introducing yet another dependency cycle with
> harfbuzz.
  Yup, this needs testing.

> Do you see any other options? Which route do you prefer?
  I'd prefer the third route. Drop icu-le-hb as it's already abandoned and
only used by OpenTTD via the Paragraph Layout API. This is discussed in an
other bug report, #897233 [1]. Matthijs, may you know more about the
background work, how it goes in OpenTTD? Is there any upstream bug report
about this to follow?

Cheers,
Laszlo/GCS
[1] https://bugs.debian.org/897233



Bug#898571: build dependency cycle between icu and icu-le-hb

2018-05-13 Thread Helmut Grohne
Source: icu
Version: 60.2-1
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

icu introduces a build dependency cycle with icu-le-hb. Doing so breaks
architecture bootstrap. The full cycle is:

src:icu Build-Depends: libicu-le-hb-dev
libicu-le-hb-dev is built from src:icu-le-hb
src:icu-le-hb Build-Depends: libicu-dev
libicu-dev is built from src:icu

I haven't fully understood the reason of the new dependency yet, so I
cannot easily suggest a cure. One thing that strikes me as odd is that
these source packages seem to be fully interdependent. That suggests
that merging them into a single multi-tarball source package might work.

Reading http://userguide.icu-project.org/layoutengine/paragraph suggests
that doing so may be impossible, because that'd require adding harfbuzz
to icu's Build-Depends introducing yet another dependency cycle with
harfbuzz.

An alternative may be splitting icu-lx into separate binary packages
libiculx60 and libicu-lx-dev. Then we could add a build profile
pkg.icu.nolayoutex to skip generating these packages. Downstream users
would have to add an explicit dependency on libicu-lx-dev to get that
functionality.

An even better variant would be splitting icu-lx into a fully separate
source package if possible. Potentially moving icu-lx into libicu-le-hb
might work.

These ideas concentrate on the src:icu -> libicu-le-hb-dev edge. As far
as I understand, trying to build src:icu-le-hb without libicu-dev
doesn't make any sense at all (and still produces a cycle via harfbuzz).

Do you see any other options? Which route do you prefer?

Helmut