On Wed, May 16, 2018 at 10:42:50AM +0200, Francois Gouget wrote: > libicu-dev is not multi-arch aware, causing the i386 version to conflict > with the amd64 one which makes it impossible to install both. As a > result the /usr/lib/i386-linux-gnu/libicu*.so symbolic links are missing > so that developping 32 bit applications using this library is > impossible on a 64 bit system.
This is correct. The problem here is that libicu-dev ships icu-config. The behaviour of icu-config is architecture-dependent, but its path is not. There is no way to have it behave correctly for two architectures simultaneously. As long as icu-config is shipped, it cannot be coinstalled. That puts us between a rock and a hard place. > The lack of multi-arch support in libicu-dev also breaks multi-arch > support in the following packages: fis-gtm-6.3-003a libboost-regex1.62-dev > libcdr-dev libe-book-dev libharfbuzz-dev libical-dev libmspub-dev > libvisio-dev libxslt1-dev. So the impact is quite wide ranging. icu-config is deprecated upstream already, but still used in a variety of downstream packages including libreoffice, qtwebkit-opensource-src, libxml2, chromium-browser and many more. The impact of removinig icu-config has worse consequences. For the time being, fixing this is impractical. On the other hand, this tells us how to fix the issue: Make packages stop using icu-config. Use pkg-config icu instead. When you send patches, I suggest that you add a "block 898820 by $yourbug" to track progress. Another way to make a dent is tracking the size of the problem: Perform an archive rebuild with icu-config removed and diff against a regular archive rebuild. That'll tell us which packages need fixing. One could use sbuild --starting-build-commands="rm /usr/bin/icu-config" to do that. Thanks for your help Helmut
