On Thu, 3 Feb 2011 15:39:49 +0000 Wookey <wookey@wookware.org> wrote: > dpkg-cross in fact only picks files out of packages by positive > identification as libraries or headers. It misses out generic 'other > stuff' in ((/usr)/lib, which generally works pretty well, but in > this tcl case it's not suffient for tcl-depending apps to cross-build. > > Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599206 discusses > this issue. ... and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611736 is probably going to be the root bug (renamed) to handle the clarification of exactly what files we keep and how we rationalise the legacy regular expressions in dpkg-cross. Please add further specific cases to that bug. > dpkg-cross is intended to put files needed for cross-building into > -cross packages and it's currently missing this one out. Unfortunately > because it doesn't match any of the 'standard paterns for cross-useful > files' this can only be fixed by adding a fairly specific regexp, > which is worrying close to special-casing or deciding that in fact > just fishing out specific things from /usr/lib is too conservative and we > should take the view that everything in /usr/lib is potentially useful > in cross-building and should be copied into -cross packages. Generally, from a cursory view of what is left out, the situation we have is this: 0: dpkg-cross supports autotools cross-building through a series of very detailed, very complex and potentially fragile regular expressions but, importantly, ALSO uses a series of very detailed, very complex and potentially equally fragile regular expressions on the CONTENTS of those files, some of which Debian is quietly trying to drop from packages because of other problems. (e.g .la files) 1: dpkg-cross has explicit support for pkg-config which appears to work perfectly well, principally because pkg-config is inherently less complex than the entirety of autoconf|automake|libtool|dpkg-shlibdeps etc. 2: dpkg-cross has support for CMake - although only as a direct result of 0: and 1: 3: dpkg-cross has no idea how to help SCons or any number of other build systems out there, but then it mostly doesn't have to because many of those simply don't compile stuff, (they create Arch:all packages) and the ones that do compile stuff aren't used by sufficient numbers of cross-building people for sufficient complaints to be seen for dpkg-cross to have had the support created. 4: Nobody gave a damn about Tcl until sqlite added bindings. 5: Nobody adds support to dpkg-cross until someone complains loudly enough *and* comes up with sane patches. 6: dpkg-cross has huge amounts of legacy code which someone added at somepoint because it was important but nobody has actually had the guts to unilaterally remove because we can't tell if the original package has since been fixed. (s/fixed/broken in a different way/). > In multiarch world everything in (/usr)/lib is going to end up in > /usr/lib/<archtuple> or /lib/<archtuple>, unless packages are > re-arranged to put them elsewhere, and we expect this to work > fine so perhaps dpkg-cross should start doing the same thing, and thus > discuver any problems this does potentially create. Would > that actually do any harm? What files which are currently missed out > of -cross packages would actually cause breakage if copied over into > /usr/<triplet>/lib? Let's not break dpkg-cross fundamentally for everyone though. We can choose to make a different dpkg-cross which is FAR simpler (because it blindly moves files without any kind of safeguard) but as this does not involve fixing the contents of certain files, numerous autotools packages will break. So, if people want a broken dpkg-cross for testing, let's have a dpkg-multi-cross which breaks their cross-building world (using a different Provides: and conflicting with the "standard" cross packages) and leave the existing world alone. That version of dpkg-multi-cross would be trivial to write - unpack the .deb, unconditionally move all files in ./usr/lib to ./usr/$triplet, handle /usr/include and remove everything else. Repack the .deb as -cross. Break world. > I just tried a modified dpkg-cross on a pile of packages and whilst > many come out the same, you do get quite a lot more files in some > packages and some packages that were previously null now have stuff in > them. e.g apache-modules. So there is quite a lot of bloat, but > probably no breakage. Retaining the changes to the contents of the files whilst simply adding lots more *stuff* to -cross packages is the least harmful option. However, because the contents haven't changed, it doesn't actually help us identify the issues that would arise with Multiarch much. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp8wQhNAtyJ2.pgp
Description: PGP signature