Hi Guillem, (I'm dropping Dimitri from the cc since he's no longer interested in this!)
On Sat, 30 Aug 2014 15:51:12 +0200, Guillem Jover <guil...@debian.org> wrote: > On Sat, 2014-08-23 at 18:40:28 -0700, Stephen Kitt wrote: > > OK, so I've been working on this off-and-on for the last few months, and I > > now understand why upstream went for this "cheat"... > > > > Come to think about it though, I'm not 100% sure I understand what you're > > asking. Do you want > > config.sub i686-w64-mingw32 > > to canonicalise to i686-pc-w64-mingw32 (cpu=i686, vendor=pc, > > os=w64-mingw32), > > Yes, I was talking about something like this one. But see below, seems > things might have changed (for the better)? > > > The version I've been investigating is the former, where the canonical > > form is i686-pc-w64-mingw32 (or x86_64-pc-w64-mingw32). It's doable, but > > it requires at least: > > * updating libtool so it knows about os=*mingw32* (and not just > > os=mingw32*) > > * updating gcc likewise > > * once the above are done, adding os=w64-mingw32 to config (we need to > > wait until libtool and gcc are updated to avoid instantly breaking > > anything building for mingw-w64) > > * fixing any downstream breakage (and there will be a fair amount)... > > I don't think that diverges much from what one usually needs to do for > a new port, which this really was, obviously saying that from the comfort > of not being the one who's going to be doing the work… :/. OK, at least that's clear, and it's nice to know you feel my pain too ;-). > > That's just the technical side of things. I'm not sure how easy it would > > be to convince the various upstreams and downstreams (e.g. Fedora, > > OpenSuSE, and the many projects using MinGW-w64) of the necessity of all > > this; just as an example the gcc patch is over 5000 lines so I imagine > > people could be reluctant to accept it (OK, many of those lines are > > auto-generated, but still). > > > > Before I embark on trying to discuss this with the various upstreams, > > could you clarify your exact requirements for getting this into dpkg? > > As metioned before, the prevalent assumption in dpkg-dev and in most > of the Debian packaging and system is that the vendor is irrelevant. > And you should really think about the vendor as part of the machine, > and to be the hw manufacturer, not the one providing the software. It > does not usually get exposed anywhere, not even on DEB_HOST_GNU_TYPE > style variables and we do not have DEB_HOST_GNU_VENDOR or > _GNU_MANUFACTURER style ones either for example. That makes perfect sense, thanks. I suppose it's the same reasoning which gives the usual "shortcut" armhf triplet "arm-linux-gnueabihf" which is really "arm-unknown-linux-gnueabihf". > In addition the current triplet is also just wrong, I get the impression > that it was concocted to get a free ride and to avoid what might end up > being needed to be done anyway, a “cheat” as you put it, and I've to say > I've been a bit annoyed by it because it “perverts” the GNU triplet > system and moves the burden to someone else, which means it ends up > not being free at all. Yes, that's what I meant by saying that I now understood why upstream went down this path! > But I just noticed that a proper triplet was accepted in the config.git > repo around 2012 (commit f16804b79ee5a23a9994a1cdc760cd9ba813148a), this > is what config.sub has to say: > > $ /usr/share/misc/config.sub mingw64 > x86_64-pc-mingw64 > $ /usr/share/misc/config.sub x86_64-mingw64 > x86_64-pc-mingw64 > $ /usr/share/misc/config.sub i686-mingw64 > i686-pc-mingw64 > > So, just one thought, if you are going to end up having to do the work > that would be required to add support for what amounts to the equivalent > of a new triplet, you could as well use a proper triplet, like the one > above? That triplet was actually added by the MinGW project, not the MinGW-w64 project, and is intended for their putative 64-bit support, whenever that appears; hence $ /usr/share/misc/config.sub mingw32 i686-pc-mingw32 $ /usr/share/misc/config.sub mingw64 x86_64-pc-mingw64 I'll take it up with MinGW-w64 upstream though and see what they make of it. > In the end it seems to me that as long as the triplet is officially > supported by config.sub/guess the rest of software should just follow > suit, which as mentioned before is what needs to be done for each and > every new architecture anyway. What might be more time consuming is > hunting down and updating the rest of the affected packages in Debian, > but given that this has been thought to be a partial architecture from > the beginning it should not amount to so many packages (in contrast to > a full fledged architecture, that is). I think what will be time-consuming is getting the various required patches into the various upstream projects; there are very few affected packages in Debian. Unless you mean we should just go our own way, regardless of what upstream thinks, and use the mingw64 which is already in config.sub and patch whatever breaks? I'd rather do the work required to get something supported properly in Debian and by upstream... Regards, Stephen
signature.asc
Description: PGP signature
