[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: MinGW

2008/9/20 Toshio Kuratomi <a badger 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?
Do we consider things which are only found in secondary arches as
exceptional circumstances which need some sort of oversight before
they are allowed? Do we allow things into secondary arches which will
not build in primary arches? Do we ask the following question "does
this build under the primary arches?"  regardless of the answer to "is
this useful as a binary to ship in the primary arch repos?"

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."
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.

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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]