I'd like to see the issue of the MinGW repository make it on the next available FESCo meeting.
I do not expect all the details to be dealt with in a single meeting.
Though I would like FESCo to be able to grant the MinGW SIG some probationary authority to use koji to build packages for testing purposes as per the comments here:
As requested in response to the Board meeting where this was addressed, here is a strawman proposal on how to move forward with the creation of a MinGW repository for noarch packages built using MinGW:
Here also for reference is the Infrastructure Ticket opened by the MinGW SIG with the initial resource allocation request:
I've added this to agenda for 9-10-08 FESCo meeting.
There was a stated intention in today's meeting to avoid packaging Windows executables on the part of the MinGW SIG and primarily focus on DLLs.
I'm not sure that is actually going to be implementable as a policy statement.
For what they need to do to build up the development environment they are interested in using the may in fact need to include several windows executables.
I point to this:
And then there is this:
It's very difficult to draw a line between libraries and executables in terms of desirability as a payload. I made no effort to do that in the draft because I was unable to think of a defensible reason to make the distinction. Nor appearantly have the MinGW SIG developers.
Building policy based on the intended use of the executable is going to make for very provocative review situations. Do we want to get into a situation as a matter of policy that a package submitter must prove that an EXE is needed as a development tool in the build process of something else?
If EXEs must be included to form the basis of a development environment, then perhaps EXEs for other desired reasons should be expected to be included and we should plan for that? If the technical packaging policies must allow for EXEs to be included as part of the development environment, as they clearly must, on what grounds do you forbid other EXEs? Yes the current MinGW SIG members do not anticipate needing other things, but when building policy we must anticipate that other community members will want to make use of this process for their own reasons. We've never asked submitters as to the reason for wanting the package and we probably shouldn't start doing it with these.
What would prevent someone from doing the work necessary to submit gedit to be compiled with MinGW and included as a windows EXE under fedora following these steps:
or for that matter emacs
I think we can all agree that emacs is a development tool. Even the vi-lovers must conceded that, even if they think its the wrong development tool to dominate the world.
If you include EXEs as potential payloads..the potential space consumption magnify beyond the conservative estimates for just library DLLs to something we as a project should not make an open ended resource commitment to. One purpose of the separate repository structure now, is meant specifically as a way to plan for a wider interest beyond what is strictly needed by the virtualization client development that is driving the initial MinGW push. Making the effort to set this up as a separate construct now, prevents the project from having to make harder decisions later in terms of resource commitments. We stand this up as its own corner of the project and we let the community who are interested in sustaining it, sustain it by adding resources as needed to help it grow beyond what the initial virtualization developers need.
Based on a recommendation from rel-eng, FESCo dropped the requirement for a separate repo for MinGW.
to comment on this ticket.
Copyright © 2014-2017 Red Hat
3.3 — Documentation