On 2 February 2015 at 19:08, Helmut Grohne <hel...@subdivi.de> wrote: > On Mon, Feb 02, 2015 at 05:32:19PM +0000, 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 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. 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)? -- 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
