Hi! [ I'm leaving for two days, and running out the door just right now, so this mail is a bit rushed, and might contain inaccuracies and repetition due to lack of proper review, sorry about that, I'll try to clarify anything unclear once I get back. ]
On Tue, 2010-09-07 at 14:01:37 +0300, Konstantinos Margaritis wrote: > I really would like to know the stance of the dpkg maintainers regarding > the > armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as > bug reports, but without the dpkg patch, those patches would be useless, so > I'm holding back, but that in the meantime increases the workload as newer > packages appear all the time and I have to forward port the armhf patches all > the time. Plus, the whole port is unusable without dpkg functioning properly. > The patched version I have uploaded in debian-ports works fine without any > side-effects whatsoeer. I'm not asking for immediate acceptance, but even a > short mail of 'it's ok, but needs more work here and there' will do. I don't quite like the current implementation, which abuses the vendor for information related to the ABI. So, recapping a bit the long thread about the new port: I agree with Paul Brook that abusing the vendor in this way poses a compatibility issue with upstreams, I'd rather not use something like this which is probably Debian specific. We currently need something like this in dpkg-dev because the mappings need to be bidirectional, as dpkg-dev needs to be able to convert from GNU triplet to Debian architecture and the other way around. Steve wondered why this is the case, and that's because for cross-compiling purposes dpkg-architecture infers the host architecture from the CC environment variable through the -dumpmachine option. Chaning this is possible but, would break a current way of cross-compiling which has been around for a long time. The toolchain has the same triplet for binary incompatible producing objects, which seems like a bug/misfeature to me, and that's one of the assumptions dpkg-dev has relied on, in the same way as multiarch when deciding to use the triplet as a unique token for the installation directories. Although one can produce binary incompatible output with normal gcc options, like changing the calling conventions with something like for example -fpcc-struct-return, but those are not part of the default ABI, and are expected and warned as producing incompatible binaries. This also causes issue with not being able to have installed two cross-toolchains for say armel and armhf as they share triplet, although you can use the armel toolchain with few options to build for armhf, but then you'd need to specify those as part of the CC variable. Also that also happens with biarch, you can produce i386 binaries from an x86_64 toolchain, yet they both have their own triplet. I'm just wondering if this is also the case for mips triarch, or do those have each their own triplet, and is only arm that has this issue? Anyway, ideally I'd rather see this addressed by giving armhf a real triplet, which would also make multiarch life way easier as there'd not be any need to define an artificial set of neutral architecture names to be able to place objects in the file system. But if this is not going to happen, and thus the assumptions dpkg-dev is making have been just wrong, then I'd rather drop the bidirectional mappings, and be done with it. This will need careful consideration though, as it's breaking a current interface, but something that could be done for dpkg 1.16.x. I can propose a patch for this once I get back. thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org