On Fri, Jul 11, 2008 at 9:47 AM, Toshio Kuratomi <a.badger@xxxxxxxxx> wrote: > We've already established that mingw doesn't fit the model of secondary > arches but does it fit the model of EPEL and OLPC? Have we? I'm not sure we have enough people talking about it yet.. to be sure. I have questions, I'm deliberately playing the ignorant fool (when in doubt go with what you know) hoping someone with intimate knowledge on where the 2ndary arch infrastructure chimes in on whether or not we can setup a mingw built tree 'like' a 2ndary arch. > Can we have a repo/sub > project that has its own branches of packages in CVS and builds that target > windows using mingw on Fedora? Is that something we have enough interested > parties to do? Can we? We'd need to think hard about how we want to integrate any mingw spec logic into existing specfiles for libraries. Or do we let the mingw specfiles run completely parallel to our existing packages and not try to work mingw logic into our existing specs? I think the cross-compiler aspects of mingw bring some unique packaging challenges on us, that far surpasses the sort of problems we've seen with trying to support EPEL as branches in our existing cvs for example. Looking at the -devel-list thread concerning dep resolution work arounds tells me doing this right isn't going to following an easy-bake-oven recipe. For example, is it going to matter as to what branch of Fedora mingw built DLL's are actually built on? Or can we lump DLL packages together into a single repository regardless of which version of Fedora they were actually built inside of? If we setup a mingw built repository would it need to have release branches that matched the Fedora release branches? Or can we get away with a mingw repository with its own release branching schedule that was not tied directly to the Fedora release schedule? Since none of the resulting DLL payloads can be used natively on Fedora... can you essentially 'use' such a standalone mingw repository equally well across different Fedora versions to install DLL packages? Certainly right now there is a a small..core..group of developers who are pushing mingw compiled libraries forward specifically for libvirt client needs. Can we set aside some initial project infrastructure space of a specified size for an initial mingw branch and master repository..with the understanding that as it grows in popularity people working inside that branch will need to bring additional infrastructure to the table..such as mirrors and potentially master hosting space as the size of the binary pool grows significantly? I've no problem expending project resources as a genesis for a mingw built repository of packages, but I'm not sure we can make a commitment to host a fully realized mingw built library space given pressure to host other contributed materials. In that sense its a lot like 2ndary arches. If the mingw branch is going to be successful, we are going to need its contributor and userbase to bring some infrastructure to the table for it. > Note: This may or may not scale very well when we think of expanding it to > the realm of all cross-compilers. But we probably aren't talking about > potentially rebuilding every library in Fedora for the Lego MindStorm :-) This won't be the last cross-compiler of import that we are going to have to deal with. And I'd rather craft a general framework for this sort of thing now, that we are comfortable with using as a starting point in the general case when we have another cross-compiler sub-community wanting to do work within the Fedora project umbrella. -jef _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
