On 3 December 2013 22:42, Stephen Kitt <sk...@debian.org> wrote: > Hi Guillem, > > On Sat, Aug 11, 2012 at 03:34:07PM +0200, Stephen Kitt wrote: >> On Wed, 8 Aug 2012 13:01:03 +0200, Guillem Jover <guil...@debian.org> wrote: >> > Sorry, I thought I had replied but it appears that was not the case, >> > it was on my radar to come back to it anyway, thanks for the reminder. >> > >> > The main issue I have with this request is that the upstream triplet just >> > seems wrong, as it encodes part of the ABI in the vendor field. That's >> > AFAIR, from reading the thread back then. >> > >> > For dpkg tools the vendor is irrelevant, and having to take it into >> > account would imply changing the underlaying infrastructure which >> > might not be a problem per se, if the reason for requiring this wan't >> > wrong. >> >> I take it you're referring to the "w64" portion, differenciating MinGW-w64 >> from MinGW? I've been using the attached patch (which I'll explain further >> down...) with pretty good results; what would break in dpkg if we wanted >> correct support for the vendor? Currently I can specify "mingw64-x86" as an >> architecture; wouldn't it be possible to have a "mingw-x86" architecture, >> with the appropriate entries in triplettable and ostable, for MinGW support >> without any other changes? >> >> > I'm not sure if it's too late now to consider changing the triplet >> > upstream, I should probable have brought this up long time ago, but >> > then it seemed to be pretty settled down already. :/ >> >> I think it is too late, everyone else (MinGW-w64, the many projects using >> it, and the various other distributions supporting it) has already switched >> to it. >> >> > OTOH, is dpkg buildable and usable at all on mingw-w64 systems? I >> > understand though that there might be reasons to want the architecture >> > supported so that cross-building is allowed, but then the request does >> > not seem pressing, and that's one of the reasons I've not acted on it >> > before. >> >> As Dmitrijs explained in his reply, all the MinGW-w64 stuff in Debian is >> likely to only ever support cross-compilation, not end up being a full >> architecture hosted on Windows. The main reason to have the support in dpkg >> is to start building the infrastructure required for a partial architecture, >> so we can more easily provide libraries etc. (see for example >> http://bugs.debian.org/671437). > > Is there any chance the attached version could go in? It's against > current git, minus the previous changes to cputable which were wrong. > > Now that Debian is increasingly cross-buildable, and with sbuild and > cross-build-essential providing an excellent environment to work in, > it would be great to have mingw-w64 support in dpkg... Unless you have > objections of course! >
I've carefully reviewed the whole thread and re-reviewed the proposed patch: * vendor tag is _not_ used to encode API/ABI, GNU_SYSTEM is "w64-mingw32" - GOOD (agreed by everyone in the thread) * Debian.pm is correctly patched to disable features, which are not support - GOOD * no changes to cputable - GOOD [2] Another point raised was: * dpkg ported to w64-mingw32 Actually at the moment that's not needed at all, as at this stage w64-mingw32 port will be purely cross-compiled and multiarch enabled only, therefore dpkg is needed for the build_os. Naturally building as many packages for w64-mingw32 platform as possible will be a priority. Please include patch as attached at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825#182 If there are any other questions / concerns, please raise them now. [1] if any bugs would arise from that, the porting team will provide patches / upstream fixes as needed. in practice, we don't expect any from well-behaved software. [2] as noted in #611741, a generic implementation is not yet available to map/select baseline CPU features on a per debian architecture (e.g. i486 vs i686, ARMv5 vs ARMv6 vs ARMv7hf etc) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
