#807 MinGW needs a new Fedora repository
Closed: Fixed None Opened 15 years ago by rjones.

In accordance with: http://fedoraproject.org/wiki/Board/Meetings/2008-07-15
the MinGW SIG needs a separate Fedora repository to host our RPMs.


This falls under secondary content. We'll need to create a group name and repo for it.

I'll create a group called mingw who should the owner be?

Also how much space will you be needing over the next 3 months. How much over the next year?

Group name: mingw

Can we assign the owner to a mailing list or SIG? Some time ago we requested a specific mailing list, here:
https://hosted.fedoraproject.org/fedora-infrastructure/ticket/689
If not then I can own it.

Space is of course somewhat hard to estimate, but nevertheless I will try.

For the three month target, I assume it will take us at least this long to get just our current list of packages in. Apart from a few base packages, all packages are built as 'noarch'. At the moment, the packages we have (RPMS + SRPMS) occupy 200 MB.

So I would say, allowing for nice multipliers:

  • 3 months: 2 GB
  • 12 months: 8 GB

Let me know if those numbers are far too large (or small) for consideration.

Just to clarify a little further - we'll want these repositories to align with main Fedora repositories, likewise for the koji build target inheriting from the Fedora build targets.
Fedora 10 will be the first release we'll formally build these MinGW packages for, so the build target would currently need to inherit dist-f10. So perhaps 'dist-f10-mingw' for the build target, and the 'mingw' yum repo in some location that matches rawhide yum repos. When F10 goes GA, we'll need to switch dist-f10-mingw to align with F10 release tree locations, and have a new dist-f11-mingw, for the rawhide yum repos.

As to the issue of space.

It would be best if space estimates were such to anticipate some additional community interest in building beyond current identified virt needs. Not big enough to rebuild the entire library collection currently in Fedora, but if someone comes to the MinGW SIG and makes a compelling case for a new library to be included in the MinGW built repo, there should be enough space for the MinGW SIG to accommodate some of those requests on whatever basis the MinGW wants to use to evaluate those requests.

I would think that it would be appropriate to allocate twice the needed space beyond what is strictly anticipated for just the virt related libraries as an initial space allocation.

-jef

I guess I was trying to anticipate that by multiplying my expected needs by 10. I'm torn between a "disk is cheap" argument [I just bought 1.5 TB of disk last week for $300] versus knowing that everything we do will be mirrored 100s of times around the world.

So the estimates above are for libvirt needs (x 10). We've had some community interest and I expect a lot more because we are really going significantly above and beyond what Debian offer. The ability to sit in an entirely Fedora environment and build a Windows installer of a complex package that may depend on many Linux libraries without needing to touch a damn Windows machine -- definitely awesome for a certain group of programmers.

Based on comments from other people on fedora-devel about mingw, I'd expect at the very least we'll see the core GTK libraries built for mingw, and potentially python core + pygtk library. That'd add another 100 MB of RPMS/SRPMS - NB, since its cross-compiled most mingw stuff is actually 'noarch', so we don't have the ppc/i686/x86_64/etc combinatorial increase in binary RPMs.

Replying to [comment:6 rjones]:

I guess I was trying to anticipate that by multiplying my expected needs by 10. I'm torn between a "disk is cheap" argument [I just bought 1.5 TB of disk last week for $300] versus knowing that everything we do will be mirrored 100s of times around the world.

Cheap disks are in fact cheap. But disks that come with on site warranties + the cost of that onsite warranty. Not cheap.

Ok, another question. There's some confusion. You're just asking for distribution right? You aren't asking for a buildsystem? "repo" has too many definitions these days

Side note, if one of you guys could come talk to me in #fedora-admin I'd appreciate it.

more comments :)

Ok, from an infrastructure perspective we can host this on the mirror without issue. in the ranges they are talking about this won't be an issue. From what I understand from the board is they wanted to see if its available but it is not approved yet. If I'm wrong in this please correct me but there's no blockers from an infrastructure side to host the distribution of these bits.

Conversation in #fedora-admin

09:20 < mmcgrath> rwmjones: ok, you do, in fact, need to build these packages on koji?
09:20 < rwmjones> mmcgrath, yup

I'm going to cc dennis about that portion.

So I was asked to document everything we would be wanting to do with this repository.

The answer is .. everything, ie. build in Koji for all branches of Fedora and EPEL,
use Bodhi to manage packages, Bugzilla, etc etc. Just like we would normally build
and manage Fedora packages.

to be able to complete second repos from an infra stance the follwoing work is needed

create seperate cvs trees
create new tags and targets in koji
create new targets and mock configs in plague for building against EPEL
new bugzilla products created.
either fedora-release updated or a mingw-release packaged created (with FESCo needing to allow the exception to the guidelines)
trees on mirrors created.
new rsync targets for mirrors.
bodhi, mirrormanager, packagedb told about the product.
new gpg keys created for each release of fedora to be supported.
releng process for signing and pushing packages. X 2 epel and fedora use seperate releng.

all up it will take 1-3 weeks of work to complete

forgot to mention comps will need to be setup with translations also.

Ok, couple of problems from rel-eng side.

1) EPEL doesn't use koji, it uses plague, so yet another system that would have to grow target information related to mingw.

2) Bodhi only knows how to deal with one product, Fedora, at least in our current configuration. Perhaps Luke can bring up a second bodhi instance specifically for mingw. Adding him to the cc list.

3) package signing. If this isn't "Fedora" I don't think it's appropriate to sign the packages with the Fedora keys, so mingw will have to come up with its own keys, or releng will have to create/manage them. This just adds more complexity.

4) composes. I don't know the details of what a mingw repo would look like, or what considerations it needs during compose time. Don't know if we'll have to modify mash at all for it.

It would probably be best if somebody from the mingw group shows up at the next release engineering meeting for a talk about what it'll take to get you rolling. We meet Mondays at 1700 UTC.

It would probably be best if somebody from the mingw group shows up at the next release
engineering meeting for a talk about what it'll take to get you rolling. We meet Mondays at
1700 UTC.

Yes, no problem -- in my diary.

At the meeting on 2008-10-13, rel-eng discussed MinGW:

https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-oct-13

The conclusion is below (copied from the above web page)


MinGW Repos

reviewed the amount of work necessary to support MinGW built packages in their own repo and determine whether it's "worth" the work

built packages are installable and usable under fedora (with wine, or if you're compiling something that BuildRequires them)

example: http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html

CONCLUSION:

A lot of work to get these packages in their own repo with little perceived benefit

Report back to Fedora Board:

Release Engineering believes the return on investment for making a separate repo for MinGW built packages is too low and the amount of work too high at the present time.

Release Engineering believes this issue would be worth revisiting in the future if space becomes an issue in the future

Closing this bug because FESCo have agreed with the rel-eng
decision to do without a separate repository at this time.

Login to comment on this ticket.

Metadata