Ticket #807 (closed task: fixed)

Opened 6 years ago

Last modified 5 years ago

MinGW needs a new Fedora repository

Reported by: rjones Owned by: mmcgrath
Priority: major Milestone: Fedora 10
Component: General Version:
Severity: Normal Keywords:
Cc: berrange@…, poelstra@…, ausil, jstanley, jkeating, lmacken Blocked By:
Blocking: Sensitive:

Description

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

Change History

comment:1 Changed 6 years ago by mmcgrath

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?

comment:2 Changed 6 years ago by rjones

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.

comment:3 Changed 6 years ago by berrange

  • Milestone changed from Fedora 11 to Fedora 10

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.

comment:4 Changed 6 years ago by berrange

  • Cc berrange@… added

comment:5 follow-up: ↓ 7 Changed 6 years ago by jspaleta

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

comment:6 follow-up: ↓ 8 Changed 6 years ago by 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.

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.

comment:7 in reply to: ↑ 5 Changed 6 years ago by berrange

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.

comment:8 in reply to: ↑ 6 Changed 6 years ago by mmcgrath

Replying to 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.

comment:9 Changed 6 years ago by mmcgrath

  • Owner changed from nobody to mmcgrath
  • Status changed from new to assigned

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

comment:10 Changed 6 years ago by mmcgrath

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

comment:11 Changed 6 years ago by mmcgrath

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.

comment:12 Changed 6 years ago by poelstra

  • Cc poelstra@… added

comment:13 Changed 6 years ago by mmcgrath

  • Cc ausil added

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.

comment:14 Changed 6 years ago by rjones

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.

comment:15 Changed 6 years ago by jstanley

  • Cc jstanley added

comment:16 Changed 6 years ago by ausil

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

comment:17 Changed 6 years ago by ausil

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

comment:18 Changed 6 years ago by jkeating

  • Cc jkeating, lmacken added

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.

comment:19 Changed 6 years ago by rjones

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.

comment:20 Changed 6 years ago by rjones

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

comment:21 Changed 5 years ago by rjones

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

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

Note: See TracTickets for help on using tickets.