MinGW

[Josh Boyer]

On Sat, Sep 20, 2008 at 12:03:29PM -0800, Jeff Spaleta wrote:
>2008/9/20 Toshio Kuratomi <a.badger at gmail.com>:
>> On the other hand, what we want to know is why we should impose an
>> additional restriction on packages destined for use in a crosscompiler.
>>   Jef, care to lay out the reasons for this restriction?
>
>I will answer your question with a number of other questions.
>
>How do we handle arch specific things for secondary arches right now?

We don't.  There are no official secondary arches.

(White lie).

>Do we consider things which are only found in secondary arches as
>exceptional circumstances which need some sort of oversight before
>they are allowed?

We have Exclude/Exclusive arch tracker bugs.  That's it.  From a CVS
standpoint, everything must build out of the canonical Fedora CVS repository
for all architectures.  The MinGW package set would not differ from this
rule either, and I have seen _no_ indication that the MinGW SIG has ever
suggested otherwise.

>Do we allow things into secondary arches which will not build in primary
>arches? 

Yes.  Even among "primary" arches this is allowed.

>Do we ask the following question "does this build under the primary arches?" 

No.  And we shouldn't, because if we did that we'd never have anything
worthwhile for secondary arches.

>regardless of the answer to "is this useful as a binary to ship in the
>primary arch repos?"

Nope.

>Perhaps FESCo doesn't think this should be a hard requirement, but
>instead situations should be flagged for review and taken up by some
>sort of oversight group on a case-by-case basis. Or maybe FESCo
>disagrees completely with this and doesn't think an oversight is
>needed.  If FESCo thinks this particular restriction is unnecessary I
>will defer to their decision on the matter.  But if FESCo does
>disagree with me I'd like to see a policy statement with regard to
>this matter that is generally applicable to the nature of
>"primary-ness". How committed are we to the "primary arches".. and in
>what sense are they "primary."

Ok, first of all you keep making statements about secondary architectures
and differences from primary architectures.  An architecture, primary,
secondary, or otherwise, will by nature carry packages that are exclusive
to that architecture.  This is a fact of life and trying to build exception
clauses in for checking "primary applicability" is basically going to just
add a hurdle that really doesn't need to be there.  It does not _help_
anything.

Secondly, you keep comparing MinGW to a secondary architecture.  It is NOT.
This is a (relatively) new class of support in the Fedora ecosystem.  Namely,
this is cross-compiling support.  We have cross compilers and toolchains today.
What the MinGW folks are trying to do is expand upon that and provide
additional packages to ease packager/developer burden when cross compiling
applications.

There are certain similarities to be sure, so it is not an unreasonable
jump to compare cross compiling to secondary architectures.  However, I believe
the scope, technical implications, and target audiences are different enough
that by doing such comparison one will inevitably cloud the issues for both
enough that nothing good for either will come of that.

>Even if it can be successfully argued that mingw payloads are not
>equal in scope to a full primary arch, I do not personally consider
>them to be part of the primary arch mandate as I understand it. If
>FESCo thinks they are part of the primary arch mandate, I want to see
>a treatise on that which details why.

What primary arch mandate?

>As to the whole on by default or not... the main thrust here is that I
>don't think its appropriate to mandate that this repo be turned on by
>default in all Spins. I think, at least for the time being. The mingw
>repository definition should be up to the individual Spin maintainers
>to have enabled or disabled by default. And even during the FESCo
>meeting, it was suggested that a mingw-release  rpm could be included
>instead of defining this in the fedora-release. And you know what,
>that sort of makes some sense too...if these mingw packages could be
>cross-distro in nature. If OpenSuse made available the mingw toolset
>in their main repository... would they be able to make use of the same
>mingw payloads that are the focus of this discussion once we put them
>in their own repository space? I hadn't thought of that before now. If
>that would be a very nice secondary benefit, if our mingw SIG wanted
>to reach across the aisle and get OpenSuse's community to build
>something we could all equally use.

I don't really disagree with anything you say there, so I won't comment.

>To be clear the Board mandate itself was limited to requiring to
>putting these things into a separate repository structure, and not in
>the main repository.  I've seen no discussion which would indicate
>this is not technical possible to do.   Other things in the draft are
>my own thinking about how best to do that in more detail.  I took
>Josh's request  for a draft as a request for something more
>comprehensive than just "thou shalt put this in a separate repository"
>when he asked me to draft something.   Please don't confuse the
>implementation detail suggestions with the underlying mandate.  I
>probably could have done a better job separating the mandate from the
>suggestions.

I belive (and I stated as much in the FESCo meeting where we talked about
this briefly), that the crux of the issue with your proposal is the "needs
to build natively" item.  That is the issue FESCo needs to further consider,
along with the packaging guidelines that the MinGW SIG is drafting.  Those
are the items that require careful thought, and not just for MinGW.  The
draft guidelines I have seen so far have nothing overly MinGW specific about
them, and _should_ be easily usable for cross-compile packages in the future
as well.

josh