Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On Fri, Feb 06, 2015 at 10:32:15AM +, Dimitri John Ledkov wrote:
I thing ultimately we do want to drop icu-config. That would have to
be a mass-bugfile icu-config is to be dropped, which will make your
package FTBFS, followed on by patches / MUs / NMUs, followed by
dropping icu-config - RC bugs, migration complete.
Yeah, we observed that we agree on the long term vision already.
An interim solution could be to split icu-config binary into it's own
M-A:nothing package, but imho that's too late for jessie, and makes
not much sense for jessie+1 given that we would drop that.
Well, let me further that thought a bit. Packages that use icu-config,
do so by Build-Depending on libicu-dev, so libicu-dev would have to
depend on the that new package. Since that new package is M-A:no (it's
neither none nor nothing but no), libicu-dev would effectively
become M-A:no as its dependencies cannot be satisfied for multiple
architectures simultaneously. At that point we can merge the new package
into libicu-dev dropping M-A:same.
So the actual implementation of this sketch would be:
* Move icu-config from icu-devtools to libicu-dev.
* Turn libicu-dev M-A:no.
* Add relevant Replaces.
Can you elaborate what is broken by dropping M-A:same? Most of the time,
well one needs icu-devtools for build architecture, and icu-dev for
host architecture. However, the full combination of tools used during
compilation inside Ubuntu touch SDK need to compile native tools which
happen to link against icu-dev, thus the enablement of making icu-dev
to be M-A:same.
In this case, I suggest to keep Ubuntu independent of Debian. The
removal of M-A:same is meant to be temporary. Ubuntu doesn't have to
follow.
I think that removing M-A:same from libicu-dev is a fair compromise
between ensuring that nothing breaks natively and enabling some
cross-compilation.
I prepared a patch, but it is yet untested due to -ENOSPC here.
Maybe we can be pragmatic and fix icu-config script to call into
pkg-config and make it multiarch aware without changing any binary
packages (that is not move things between binary packages, nor
introduce new packages nor change the M-A headers on existing
packages)?
As much as I'd like this to be possible: It isn't. In order for
pkg-config to work with cross-building properly it must be called via
the cross-wrapper i.e. as $(DEB_HOST_GNU_TYPE)-pkg-config. When
icu-config is invoked, we already no longer know which architecture is
destined to be the host architecture, so we do not know how we would
have to call pkg-config.
Helmut
diff -Nru icu-52.1/debian/changelog icu-52.1/debian/changelog
--- icu-52.1/debian/changelog 2015-01-22 03:47:39.0 +0100
+++ icu-52.1/debian/changelog 2015-02-06 19:39:01.0 +0100
@@ -1,3 +1,13 @@
+icu (52.1-7.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Move icu-config to a M-A:no package. (Closes: #776821)
++ Move icu-config from icu-devtools to libicu-dev.
++ Declare relevant Breaks and Replaces.
++ Remove Multi-Arch:same from libicu-dev.
+
+ -- Helmut Grohne hel...@subdivi.de Fri, 06 Feb 2015 19:29:44 +0100
+
icu (52.1-7) unstable; urgency=high
* Patch to CVE-2014-6591, CVE-2014-6585 a font parsing bug.
diff -Nru icu-52.1/debian/control icu-52.1/debian/control
--- icu-52.1/debian/control 2015-01-22 03:47:39.0 +0100
+++ icu-52.1/debian/control 2015-02-06 19:32:19.0 +0100
@@ -32,9 +32,10 @@
Package: libicu-dev
Section: libdevel
Architecture: any
-Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${shlibs:Depends}, libicu52 (= ${binary:Version}),
icu-devtools (= ${binary:Version}), libc6-dev | libc-dev
+Replaces: icu-devtools ( 52.1-7.1~)
+Breaks: icu-devtools ( 52.1-7.1~)
Suggests: icu-doc
Description: Development files for International Components for Unicode
ICU is a C++ and C library that provides robust and full-featured
diff -Nru icu-52.1/debian/icu-devtools.install
icu-52.1/debian/icu-devtools.install
--- icu-52.1/debian/icu-devtools.install2015-01-22 03:47:39.0
+0100
+++ icu-52.1/debian/icu-devtools.install2015-02-06 19:30:38.0
+0100
@@ -1,3 +1,12 @@
-usr/bin
+usr/bin/derb
+usr/bin/genbrk
+usr/bin/gencfu
+usr/bin/gencnval
+usr/bin/gendict
+usr/bin/genrb
+usr/bin/icuinfo
+usr/bin/makeconv
+usr/bin/pkgdata
+usr/bin/uconv
usr/sbin
usr/share/man
diff -Nru icu-52.1/debian/libicu-dev.install icu-52.1/debian/libicu-dev.install
--- icu-52.1/debian/libicu-dev.install 2015-01-22 03:47:39.0 +0100
+++ icu-52.1/debian/libicu-dev.install 2015-02-06 19:30:52.0 +0100
@@ -1,3 +1,4 @@
+usr/bin/icu-config
usr/lib/*/lib*.so
usr/lib/*/lib*.a
usr/lib/*/icu
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On 2 February 2015 at 19:08, Helmut Grohne hel...@subdivi.de wrote: On Mon, Feb 02, 2015 at 05:32:19PM +, Dimitri John Ledkov wrote: 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. Funny, cross building libxml2 only works after dropping M-A:foreign, so your claim clearly is wrong. The reverse holds: Dropping M-A:foreign makes some reverse depends of libicu-dev cross-buildable! Also note that icu itself is not cross-buildable. I shall send a patch for this issue. Jokes aside, I do recognize that dropping M-A:foreign poses a regression and that we want to avoid this. I proposed it, because it disables functionality instead feeding wrong configuration to builds. The real solution of course involves keeping M-A:foreign on the devtools. 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. In that case, icu-devtools should simply not be containing icu-config. Furthermore, all packages using icu-config should be RC-buggy. If you agree, I shall clone bugs for the following packages (over-approximation): prelude-lml openttd 389-adminutil libfolia texlive-bin qt4-x11 libe-book xdvik-ja harfbuzz 389-dsgw gnustep-base iceweasel ncbi-blast+ dwdiff open-vm-tools chromium-browser autoconf-archive gnustep-gui libreoffice grcompiler qtwebkit libvisio yaz openjfx libcdr dee ibus-qt fis-gtm 389-admin 389-ds-base php5 webkitgtk libxml2 wine-gecko-2.24 an couchdb raptor2 0ad ucto phantomjs xerces-c python-apsw mozjs24 node-stringprep sword texlive-base icedove libmspub parrot qtwebkit-opensource-src frog I thing ultimately we do want to drop icu-config. That would have to be a mass-bugfile icu-config is to be dropped, which will make your package FTBFS, followed on by patches / MUs / NMUs, followed by dropping icu-config - RC bugs, migration complete. An interim solution could be to split icu-config binary into it's own M-A:nothing package, but imho that's too late for jessie, and makes not much sense for jessie+1 given that we would drop that. And see more below. 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? It's a clean pbuilder chroot with i386 as a foreign architecture that selected icu-devtools:i386 instead of icu-devtools:amd64. If M-A:foreign were correct on icu-devtools, this wouldn't make a difference to the build. The correct patch is to e.g. make libxml2 to use pkg-config. I agree. 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) Can you elaborate what is broken by dropping M-A:same? Most of the time, Ubuntu touch SDK which is used for cross-compilation of Qt5 native and QML apps. In essence, it's not due to icu-config, as that is unused, but due to all the other tools in the devtools package that should be M-A:foreign. you only need the development packages for the host architecture. At which point do you need it for multiple architectures? I know that this happens occasionally, so I'd like to learn where precisely. well one needs icu-devtools for build architecture, and icu-dev for host architecture. However, the full combination of tools used during compilation inside Ubuntu touch SDK need to compile native tools which happen to link against icu-dev, thus the enablement of making icu-dev to be M-A:same. - 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. I agree that we cannot have all of the above. Still having icu-config in anything else but a M-A:no package is wrong and breaks things. If removing M-A:foreign is not an option, we should seek different solutions instead of denying the problem. Please also see the huge amount of discussions we had on this issue in the prior bug reports when icu-devtools package was introduced. Are you referring to #699763? Maybe I am missing something here. I see that all ways to move from here cause pain. From my perspective, the ideal outcome would be to remove icu-config, but clearly this is out of scope for jessie. The next solution I see may be out of scope for jessie as well: * Rename libicu-dev to libicu-dev-multiarch. * Introduce a new binary Arch:any M-A:no package libicu-dev that depends on libicu-dev-multiarch and takes icu-config over from icu-devtools. This has the following advantages: * All reverse dependencies of
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
Control: tags -1 + patch
On Mon, Feb 02, 2015 at 08:08:31PM +0100, Helmut Grohne wrote:
Funny, cross building libxml2 only works after dropping M-A:foreign, so
your claim clearly is wrong. The reverse holds: Dropping M-A:foreign
makes some reverse depends of libicu-dev cross-buildable!
Given that:
* icu-devtools currently can cause broken native builds (which is a
regression from wheezy).
* icu was not multiarch-aware in wheezy, so making it non-multiarch is
not a regression.
* Some packages (e.g. libxml2) become cross-buildable by removing
M-A:foreign.
I believe that removing M-A:foreign is the right fix with minimal
changes for jessie. To that end I created a patch. Any objections to
NMUing that?
Helmut
diff -Nru icu-52.1/debian/changelog icu-52.1/debian/changelog
--- icu-52.1/debian/changelog 2015-01-22 03:47:39.0 +0100
+++ icu-52.1/debian/changelog 2015-02-05 22:10:26.0 +0100
@@ -1,3 +1,11 @@
+icu (52.1-7.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove M-A:foreign from icu-devtools as icu-config is
+architecture-specific. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 05 Feb 2015 22:10:05 +0100
+
icu (52.1-7) unstable; urgency=high
* Patch to CVE-2014-6591, CVE-2014-6585 a font parsing bug.
diff -Nru icu-52.1/debian/control icu-52.1/debian/control
--- icu-52.1/debian/control 2015-01-22 03:47:39.0 +0100
+++ icu-52.1/debian/control 2015-02-05 22:10:34.0 +0100
@@ -44,7 +44,6 @@
Package: icu-devtools
Section: libdevel
Architecture: any
-Multi-Arch: foreign
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${shlibs:Depends}
Replaces: libicu-dev ( ${binary:Version}), icu-tools ( 52.1-3~)
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On Mon, Feb 02, 2015 at 12:36:14PM +, 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.
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).
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.
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.
Helmut
dpkg-buildpackage: source package libxml2
dpkg-buildpackage: source version 2.9.2+dfsg1-3
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Aron Xu a...@debian.org
dpkg-source --before-build libxml2-2.9.2+dfsg1
dpkg-buildpackage: host architecture amd64
debian/rules clean
dh clean --with autoreconf,python2
dh_testdir
debian/rules override_dh_auto_clean
make[1]: Entering directory '/tmp/buildd/libxml2-2.9.2+dfsg1'
rm -rf builddir debian/tmp-dbg debian/tmp-udeb
dh_auto_clean
make[1]: Leaving directory '/tmp/buildd/libxml2-2.9.2+dfsg1'
dh_autoreconf_clean
dh_clean
rm -f debian/libxml2.substvars
rm -f debian/libxml2.*.debhelper
rm -rf debian/libxml2/
rm -f debian/libxml2-utils.substvars
rm -f debian/libxml2-utils.*.debhelper
rm -rf debian/libxml2-utils/
rm -f debian/libxml2-utils-dbg.substvars
rm -f debian/libxml2-utils-dbg.*.debhelper
rm -rf debian/libxml2-utils-dbg/
rm -f debian/libxml2-dev.substvars
rm -f debian/libxml2-dev.*.debhelper
rm -rf debian/libxml2-dev/
rm -f debian/libxml2-dbg.substvars
rm -f debian/libxml2-dbg.*.debhelper
rm -rf debian/libxml2-dbg/
rm -f debian/libxml2-doc.substvars
rm -f debian/libxml2-doc.*.debhelper
rm -rf debian/libxml2-doc/
rm -f debian/python-libxml2.substvars
rm -f debian/python-libxml2.*.debhelper
rm -rf debian/python-libxml2/
rm -f debian/python-libxml2-dbg.substvars
rm -f debian/python-libxml2-dbg.*.debhelper
rm -rf debian/python-libxml2-dbg/
rm -f debian/*.debhelper.log
rm -f debian/files
find . \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path
.\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \)
\)
rm -f *-stamp
debian/rules build-arch
dh_autoreconf
find ! -ipath ./debian/* -a ! \( -path '*/.git/*' -o -path '*/.hg/*'
-o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} \; debian/autoreconf.before
autoreconf -f -i
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:52: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are
deprecated. For more info, see:
configure.ac:52:
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On 2 February 2015 at 17:19, Helmut Grohne hel...@subdivi.de wrote: On Mon, Feb 02, 2015 at 12:36:14PM +, 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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On Mon, Feb 02, 2015 at 05:32:19PM +, Dimitri John Ledkov wrote: 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. Funny, cross building libxml2 only works after dropping M-A:foreign, so your claim clearly is wrong. The reverse holds: Dropping M-A:foreign makes some reverse depends of libicu-dev cross-buildable! Also note that icu itself is not cross-buildable. I shall send a patch for this issue. Jokes aside, I do recognize that dropping M-A:foreign poses a regression and that we want to avoid this. I proposed it, because it disables functionality instead feeding wrong configuration to builds. The real solution of course involves keeping M-A:foreign on the devtools. 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. In that case, icu-devtools should simply not be containing icu-config. Furthermore, all packages using icu-config should be RC-buggy. If you agree, I shall clone bugs for the following packages (over-approximation): prelude-lml openttd 389-adminutil libfolia texlive-bin qt4-x11 libe-book xdvik-ja harfbuzz 389-dsgw gnustep-base iceweasel ncbi-blast+ dwdiff open-vm-tools chromium-browser autoconf-archive gnustep-gui libreoffice grcompiler qtwebkit libvisio yaz openjfx libcdr dee ibus-qt fis-gtm 389-admin 389-ds-base php5 webkitgtk libxml2 wine-gecko-2.24 an couchdb raptor2 0ad ucto phantomjs xerces-c python-apsw mozjs24 node-stringprep sword texlive-base icedove libmspub parrot qtwebkit-opensource-src frog 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? It's a clean pbuilder chroot with i386 as a foreign architecture that selected icu-devtools:i386 instead of icu-devtools:amd64. If M-A:foreign were correct on icu-devtools, this wouldn't make a difference to the build. The correct patch is to e.g. make libxml2 to use pkg-config. I agree. 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) Can you elaborate what is broken by dropping M-A:same? Most of the time, you only need the development packages for the host architecture. At which point do you need it for multiple architectures? I know that this happens occasionally, so I'd like to learn where precisely. - 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. I agree that we cannot have all of the above. Still having icu-config in anything else but a M-A:no package is wrong and breaks things. If removing M-A:foreign is not an option, we should seek different solutions instead of denying the problem. Please also see the huge amount of discussions we had on this issue in the prior bug reports when icu-devtools package was introduced. Are you referring to #699763? Maybe I am missing something here. I see that all ways to move from here cause pain. From my perspective, the ideal outcome would be to remove icu-config, but clearly this is out of scope for jessie. The next solution I see may be out of scope for jessie as well: * Rename libicu-dev to libicu-dev-multiarch. * Introduce a new binary Arch:any M-A:no package libicu-dev that depends on libicu-dev-multiarch and takes icu-config over from icu-devtools. This has the following advantages: * All reverse dependencies of libicu-dev will keep working natively and some will become cross-buildable (e.g. libxml2). * Packages that know about pkg-config and need libicu-dev for multiple architectures (presumably a minority) can switch over to depending on libicu-dev-multiarch. So what do we do for jessie if dropping M-A:foreign is not an option? Clearly, icu-devtools is broken natively at this point and needs some fix. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
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. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
