Hi!
On Sat, 2014-08-23 at 18:40:28 -0700, Stephen Kitt wrote:
> On Wed, 4 Dec 2013 09:06:17 +0100, Guillem Jover <guil...@debian.org> wrote:
> > On Wed, 2013-12-04 at 00:00:21 +0000, Dmitrijs Ledkovs wrote:
> > > 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)
> >
> > After checking the latest GNU config.git repo, it seems there's no
> > such system defined (with os=w64-mingw32), only <cpu>-pc-mingw32 (with
> > os=mingw32). So w64 is still the vendor, being shoehorned here as if
> > it was part of the os, which does really make sense, because mingw32
> > or cygwin, etc could be considered the equivalent of glibc on those
> > operating systems (where it is denoted as -gnu).
> >
> > I'd happily accept the proposed patch if the config.{guess,sub} pair
> > where updated upstream in that direction (i.e. support os=w64-mingw32).
> 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… :/.
> 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.
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.
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?
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).
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
