supporting closed source operating systems?

[Jeff Spaleta]

On Fri, Jul 11, 2008 at 9:47 AM, Toshio Kuratomi <a.badger at gmail.com> 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