Richard W.M. Jones wrote:
When people talk about a separate repo, it's something that would still allow this workflow to happen. The separate repo exists on the Fedora master mirror but mirrors of us have the option to include or exclude these other repos depending on their ability to carry the extra packages.On Tue, Jul 22, 2008 at 08:06:59AM -0400, Jesse Keating wrote:On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote:What is the board's rationale for putting MinGW packages in a separate repository, when other cross-compiler toolchain (eg ARM) are in the main Fedora repository. Seems to me like we're penalizing MinGW just because it happens to be related to Windows, even though MinGW's code is still just as open source as anything else in our repos.Actually I think the prevailing thought that the Board has (although it's up to FESCo to really nail it down) is that the mingw tools themselves are absolutely suitable for Fedora. The libraries compiled against it for windows use are what should be in another repo.[I'm going to prepare something more detailed, hopefully integrating efforts with the cross-compiler folks, but just on these two points ...] If we ship only the four base packages (mingw-gcc, mingw-binutils, mingw-w32api and mingw-runtime) then the only software that can be compiled is software which doesn't use any libraries. That's pretty restrictive. To compile, for example, libvirt, one needs six other libraries. As with Linux, you need the library around (foo-0.dll) in order to link. Anyone compiling libvirt would need to download the source for each of these six libraries and './configure --host=i686-pc-mingw32 ; make ; make install' before they could start on libvirt, and of course it isn't really that simple since those libraries don't all just cross-compile without needing tweaks and patches. Tweaks and patches are what spec files are for. This is why we'd like to ship pre-compiled DLLs (only) of those six libs.
This separate repo will have a yum configuration file that I think should be shipped by default. I think it should also be turned on by default. This would make the fact that there is a different repo for the packages transparent to end users. (However, this portion is something that FESCo decides, not FPC... this case would need to be argued in front of FESCo).
Who is "we"? That is the crux of your statements. If a group of Fedora contributors who are not the libvirt team decide that they want to have a complete cross-compilation environment to be able to build firefox.exe for windows under Fedora at some point in the future, I'd like us to not stand in their way. OTOH, even if that never happens, there is still the issue that MingW is not the only crosscompilation system that we want in Fedora. To scale across architectures as well as in depth on one os-architecture also has an impact on mirrors which can be mitigated by having a separate repo.I think people have somehow got the impression we want to (a) ship FIREFOX.EXE and/or (b) cross-compile every library in Fedora. I'd like to say that (a) is not our intention, ever, and (b) isn't even technically possible, nevermind that it is completely undesirable.
This is partially a FPC issue and partially a FESCo/Board issue. The four people present for the FPC meeting last week discussed this informally and there was consensus that separate packging made more sense. However, FESCo will need to decide how having a separate download repository maps to our cvs repository. The two options I see are separate packages (as discussed by FPC) and separate branches within CVS. Which one is decided will have some influence over any eventual Guidelines that the FPC writes and/or approves.My personal opinion is that if you're going to need to munge spec files in order to produce packages built against mingw, those munges need to be done outside our cvs repo as well.There are two ways that we've proposed that one could build 'mingw-gnutls'. One is as a completely separate package, another is as a subpackage of the ordinary gnutls. I investigated and built packages both ways (see links below) just to see what was technically feasible. It turns out that both methods are *technically* feasible. Which is better from technical, organizational or political points of view is a completely different question.
-Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
