Ticket #2 (closed task: fixed)

Opened 6 years ago

Last modified 6 years ago

MinGW Repository Formation

Reported by: jspaleta Owned by: bpepple
Priority: major Keywords:
Cc: Blocked By:
Blocking:

Description

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: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00298.html 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:

https://fedoraproject.org/wiki/User:Jspaleta/Draft

Here also for reference is the Infrastructure Ticket opened by the MinGW SIG with the initial resource allocation request:

https://fedorahosted.org/fedora-infrastructure/ticket/807

-jef

Change History

comment:1 Changed 6 years ago by bpepple

  • Status changed from new to assigned
  • Owner set to bpepple

I've added this to agenda for 9-10-08 FESCo meeting.

comment:2 Changed 6 years ago by jspaleta

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: http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=0bb70cc4752a;file=iconv/mingw-iconv.spec or this: http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=d82114ef16b8;file=fontconfig/mingw-fontconfig.spec:

And then there is this: https://fedoraproject.org/wiki/PackagingDrafts/MinGW#Packaging_EXEs

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: http://live.gnome.org/Gedit/Windows or for that matter emacs http://ourcomments.org/Emacs/w32-build-emacs.html

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.

-jef

comment:3 Changed 6 years ago by bpepple

  • Status changed from assigned to closed
  • Resolution set to fixed

Based on a recommendation from rel-eng, FESCo dropped the requirement for a separate repo for MinGW.

http://fedoraproject.org/wiki/Extras/SteeringComittee/Meeting-20081015

Note: See TracTickets for help on using tickets.