2008/9/20 Toshio Kuratomi <a.badger@xxxxxxxxx>: > 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 suggestions. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
