On 8 August 2012 12:01, Guillem Jover <guil...@debian.org> wrote: > Hi! > > On Wed, 2012-08-08 at 10:30:19 +0100, Dmitrijs Ledkovs wrote: >> This is an old bug. But at the debconf multiple people thought it has >> been fixed already, while I don't think it was. >> One small difference is that in the near future armhf/armel might be a >> valid cpu architecture for mingw-w64 port. >> The proposal over here http://wiki.debian.org/Mingw-W64 needs updating >> to be completely inline with the multi arch spec, since that is now >> implemented. >> >> Any updates? > > 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'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. :/ > > 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. >
I have not build dpkg. But perl and most of gnome stack is buildable and usable. So I don't think there are major blockers for dpkg. There is no kernel yet (well packaging reactos is out of scope currently, as in, i am not interested in that), but it is possible to run the executables with linux kernel + wine. Yes, the current goals are to: - provide cross-compilation environment - run libraries & windows binaries with help of wine - test packages in approx. windows environment - provide packages for windows, by wrapping the resulting debs with nsis installer for example. It's a bit of a chicken and egg type of situation: - no dpkg triplet -> no futher porting work - no further porting work -> no dpkg triplet Right now I am not asking to upload a fix into debian. I am asking for the correct triplet that will be accepted, such that if the initial partial port is sucessful/useful there will not be need to bootstrap/recompile everything again just because it is later decided to have a different dpkg triplet. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
