On 2 February 2015 at 17:19, Helmut Grohne <[email protected]> wrote: > On Mon, Feb 02, 2015 at 12:36:14PM +0000, Dimitri John Ledkov wrote: >> I do not agree with severity of this bug report, as no other packages >> are FTBFS caused by this issue. > > Is it really necessary to discuss severity of a bug with a trivial > one-line fix? Either way, let the release team or maintainer downgrade. >
huh? I don't see a trivial one-line fix here, dropping M-A:foreign from devtools will revoke cross-compilation of packages of all -dev packages that depend on icu-dev, as well as a tonne of things that are cross-compiled using multiarch on daily basis. >> 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. > > Exactly, and this is the reason why -dev packages with *-config scripts > must never become M-A:same (or hide this via a M-A:foreign -devtools > package). > icu-config binary is not in the M-A:same package. That fact is not hidden, but rather well known that one must use pkgconfig to cross-compile things against icu. >> 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. > > No, this is wrong. While the user bears the responsibility of actually > being able to execute code in the package (or not executing it), the > package maintainer bears the responsibility that the behaviour of the > contained tools does not vary per architecture. > > See for example libgpg-error. libgpg-error-dev is M-A:no, because it > contains gpg-error-config. A comprehensive discussion can be found in > bug #643341. If you find a -dev package with a *-config tool that is not > M-A:no, then this is a bug. Can you name one? > >> Are there any existing dependencies in the archive that cause to pull >> in a wrong arch icu-devtools and produce undesired effects? > > Please find a failing build log of libxml2 attached. Build-Depends were > satisfied. > That buildlog is incomplete...... i can spin up buildd-from-hell and fail a huge number of packages in Debian. See past efforts from Lucas. Could you please provide complete builldlog? Or steps that I can use to reproduce that build you provide? > Beyond this, having icu-config in a M-A:foreign package utterly breaks > cross-compilation of its reverse dependencies. There is no question > whether this needs fixing. It may be a question of whether it needs > fixing for jessie as cross toolchains didn't make it, but people do > build their own as we learned in the ctte bug. The correct patch is to e.g. make libxml2 to use pkg-config. One cannot have it all ways: - dropping M-A:same on the icu-dev package breaks existing users that cross-compile things against icu (e.g. Qt5 based apps) - having things rely on icu-config prevents things to be cross-compilable - dropping icu-config script will break a lot of native compilation which is far worse at this point in the cycle. Please also see the huge amount of discussions we had on this issue in the prior bug reports when icu-devtools package was introduced. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
