On Mon, 2 Feb 2015 08:43:14 +0100 Helmut Grohne <hel...@subdivi.de> wrote: > Package: icu-devtools > Version: 52.1-7 > Severity: serious > Justification: can cause other packages to FTBFS > User: helm...@debian.org > Usertags: rebootstrap > > The icu-devtools is marked as Multi-Arch:foreign. It contains the > icu-config program, which exposes architecture dependent paths. By > accidentally installing a wrong-arch icu-devtools, builds that use > libicu-dev (even natively) fail (execution of icu-config fails sanity > check). While this is unlikely to happen on buildds (as they generally > don't enable multiarch), it is possible on developer machines. > > An immediate remedy to solve this bug is to remove M-A:foreign from > icu-devtools and is what I would propose for jessie. > > As a mid term solution, I propose moving icu-config from icu-devtools to > libicu-dev. Then icu-devtools should be able to become M-A:foreign > again. Of course, libicu-dev must be M-A:no then and it certainly must > be M-A:no as long as icu-config is in use. > > The long term solution is to move to pkg-config and remove icu-config > entirely.
I do not agree with severity of this bug report, as no other packages are FTBFS caused by this issue. It is known that icu-config (and similar legacy/pre-pkg-config *-config binaries) are not multiarch aware, and only ever output results for the architecture they were compiled. Due to this, it is clearly a M-A:foreign package, and it is up to the user to pull in the right arch one which in most cases is the icu-devtools:native one. Are there any existing dependencies in the archive that cause to pull in a wrong arch icu-devtools and produce undesired effects? Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
