https://fedoraproject.org/wiki/PackagingDrafts/MinGW
Comments welcome. It's at a rather early stage at the moment.
There are some packages already if you'd like to take a look at them:
http://hg.et.redhat.com/misc/fedora-mingw--devel
I have some misgivings (actually a lot of misgivings) about the use of the /usr/i686-pc-mingw32 directory. See Ralf's reply to my email here for some justification:
http://sourceware.org/ml/binutils/2008-07/msg00105.html
Rich.
On Tue, 2008-07-08 at 16:58 +0100, Richard W.M. Jones wrote:
https://fedoraproject.org/wiki/PackagingDrafts/MinGW
Comments welcome. It's at a rather early stage at the moment.
There are some packages already if you'd like to take a look at them:
Just one remark based on hastly browsing your draft (I haven't read the details yet):
The name mingw32 is related to 2 items: - It's the historic name mingw had inherited from its past. Technically it is required to make config.sub working when being fed with mingw-related target triplets.
[try /usr/share/automake-1.10/config.sub i686-mingw rsp. i686-mingw32]
- There seem to be efforts related to implementing a 64bit mingw, addressing 64bit Windows. (I don't know if they made progress, I only saw patches related to an x86_64/64bit mingw being submitted to different toolchain mailing-lists)
I have some misgivings (actually a lot of misgivings) about the use of the /usr/i686-pc-mingw32 directory. See Ralf's reply to my email here for some justification:
FWIW: Any cross-toolchain uses a similar directory.
Ralf
On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote:
I have some misgivings (actually a lot of misgivings) about the use of the /usr/i686-pc-mingw32 directory.
Is this maybe something that needs to be taken to the FHS? We could be setting into stone paths that maybe the next FHS will be placing elsewhere.
Although my personal experience with the FHS showed me that it is very difficult for an outsider to get anything discussed on the FHS table. But I think Red Hat has someone in FHS, so if you ping him, maybe there will be some reaction.
On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote:
What is Fedora's motivation is promoting using Open Source on a closed source operating system? This is beyond the FPC to decide as this is a technical committee, but still a valid question and maybe one that the board should be investigating.
F/LOSS often had and has to compromise on its base principles to get a lift-off, and so does Fedora (the current exception for firmwares is such a compromise). Before there was a Linux kernel, the GNU project was "supporting" closed source Unices and by design still does so.
But we're beyond the age of this kind of symbiosis, Linux (or GNU/Linux ...) and Fedora in particular doesn't need this anymore. In fact when a patch in a Fedora package is made it often doesn't matter if it works on other Unices, sometimes not even for the Free ones.
In this case I don't see the benefits for Fedora. I just see more Open Source being hijacked for a non Open Source operating system.
Regarding the packaging for mingw tools in Fedora, Axel Thimm wrote:
In this case I don't see the benefits for Fedora. I just see more Open Source being hijacked for a non Open Source operating system.
It's an interesting question, but here's my two part counter-argument:
1. Our goal should be to benefit users of Fedora, and not just Fedora itself. In this case, the packager is simply proposing to include tools that will benefit developers who have the misfortune of needing to target the windows operating system. If I found myself in that unfortunate position, I would be very happy to find that Fedora packaged a nice set of fully FOSS tools for me to use.
2. The Open Source definition talks about discrimination against fields of endeavor. Strictly speaking, it's talking about discrimination encoded into software licenses. However, I like to think that the Fedora Project should adopt this principal in a more general way, since it is in keeping with the Open Source philosophy of freedom. But you're asking that Fedora not include a collection of fully FOSS tools because you don't like what people are going to use them for. Do we really want to set this precedent? I hope not.
AG
On Wed, Jul 9, 2008 at 3:57 PM, Axel Thimm Axel.Thimm@atrpms.net wrote:
On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote:
What is Fedora's motivation is promoting using Open Source on a closed source operating system? This is beyond the FPC to decide as this is a technical committee, but still a valid question and maybe one that the board should be investigating.
Because people have to live in a world of compromise and have to install windows, solaris, etc in virtual environments, etc.. and if they can't well the company can go buy a closed source solution that will. Usually when that happens you can pack up all those Fedora, CentOS, etc systems on your way out :(.
On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
But we're beyond the age of this kind of symbiosis, Linux (or GNU/Linux ...) and Fedora in particular doesn't need this anymore.
The actual reality, real stuff in the real world, is that 90%+ of users of desktop computer systems run Windows, another 5%+ are running Mac OS X, and almost nobody (perhaps 10, 100 people in the whole world?) are running a completely free operating system (inc. BIOS etc).
Rich.
On Wed, Jul 09, 2008 at 11:51:51PM +0100, Richard Jones wrote:
On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
But we're beyond the age of this kind of symbiosis, Linux (or GNU/Linux ...) and Fedora in particular doesn't need this anymore.
The actual reality, real stuff in the real world, is that 90%+ of users of desktop computer systems run Windows, another 5%+ are running Mac OS X, and almost nobody (perhaps 10, 100 people in the whole world?) are running a completely free operating system (inc. BIOS etc).
No one denies that, but don't we want to keep the fruits of F/LOSS to encourage more F/LOSS usage? Hijacking F/LOSS solutions back to closed source will not change the percentages above, on the contrary, you remove some of the good reasons to go Linux.
On Thu, Jul 10, 2008 at 02:06:50AM +0300, Axel Thimm wrote:
On Wed, Jul 09, 2008 at 11:51:51PM +0100, Richard Jones wrote:
On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
But we're beyond the age of this kind of symbiosis, Linux (or GNU/Linux ...) and Fedora in particular doesn't need this anymore.
The actual reality, real stuff in the real world, is that 90%+ of users of desktop computer systems run Windows, another 5%+ are running Mac OS X, and almost nobody (perhaps 10, 100 people in the whole world?) are running a completely free operating system (inc. BIOS etc).
No one denies that, but don't we want to keep the fruits of F/LOSS to encourage more F/LOSS usage? Hijacking F/LOSS solutions back to closed source will not change the percentages above, on the contrary, you remove some of the good reasons to go Linux.
For what we're proposing -- libraries, not programs -- it's good to encourage programmers on closed systems to use open libraries.
Take libvirt as an example. There are plenty of proprietary / encumbered competitors to libvirt which run on Windows -- eg. you can program directly to VMWare's APIs, or XenAPI. It's better though if we can encourage Windows programmers to program to the libvirt API instead of those proprietary competitors. It's one less piece of proprietary lock-in for those programmers, and one less thing to unscrew when they want to port their software to Linux.
However, actually maintaining the libvirt port to Windows is currently a huge pain in the nether regions. It involves me having a Windows box (not a virtual machine, mind you, because Windows really doesn't run very well when virtualized), and because Windows doesn't adhere to any sort of standard, I have to copy all the libvirt code by hand to the Windows box, try to build it using a mix of tools (which have to be installed and upgraded by hand because there's no reasonable packaging system for Windows), then fix the libvirt code which has usually broken (because no one ever routinely compiles it for Windows), then hand copy the patches back to Linux, check they don't break anything on the Linux side, and then submit them upstream.
As you can imagine, this is unpleasant, time-consuming, requires me to use a horrible proprietary system, etc.
What we're proposing is a way to do this entirely within Fedora, so we use Fedora packages, on a Fedora host, with a Fedora command line, and Fedora tools. We can do nightly autobuilds to catch problems with the Windows port early, and automatically generate Windows packages. No actual use of Windows or other non-free software in sight.
Rich.
On Thu, Jul 10, 2008 at 02:06:50AM +0300, Axel Thimm wrote:
On Wed, Jul 09, 2008 at 11:51:51PM +0100, Richard Jones wrote:
On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
But we're beyond the age of this kind of symbiosis, Linux (or GNU/Linux ...) and Fedora in particular doesn't need this anymore.
The actual reality, real stuff in the real world, is that 90%+ of users of desktop computer systems run Windows, another 5%+ are running Mac OS X, and almost nobody (perhaps 10, 100 people in the whole world?) are running a completely free operating system (inc. BIOS etc).
No one denies that, but don't we want to keep the fruits of F/LOSS to encourage more F/LOSS usage? Hijacking F/LOSS solutions back to closed source will not change the percentages above, on the contrary, you remove some of the good reasons to go Linux.
On the contrary - we are providing a viable migration path to Linux which does not currently exist, due to combined vendor lockin of VMWare & Windows. You can't switch one without the other & that's not something that it viable for people to do.
Our motivation here is not to hijack or sabotage Fedora or F/LOSS, but to promote its use and expand the userbase of Fedora.
Fedora provides an excellant platform for hosting virtual machines either with Xen or KVM. The libvirt API provides a vendor-independant managment API which helps users avoid vendor lockin to both the hypervisor, and their management tools that you see when using VMWare & other commercial virtalization projects.
Fedora has been leading the entire open source distro field in its virtualization capabilities since Fedora Core 6, and feeds into many other distros - RHEL or course, but also Ubuntu , SUSE and Solaris are following our lead in management tools.
The main competition is obviously VMWare and they have been dominant in all areas for years - every company which has a virtualization management product/application supports VMWare. We've slowly been trying to get these people to support libvirt, so that they can easily manage virtual machines hosted on Fedora. The sad reality is that most commercial management products use Windows as their base and so unless we can provide libvirt for Windows they'll not use it and thus not have any support for managing Fedora hosts, and just stick with VMWare.
Having people ignore Fedora as a virtualization platform in favour of VMWare is not what anyone wants. Hence we want to provide the cross compiler toolchain in Fedora, so that we can build libvirt client & client tools for Windows.
This will allow people with Windows desktops & management tools to make use of Fedora virtualization. This will increase the userbase of Fedora, and Linux based virtualization platforms. It will also fully establish libvirt as the primary cross-platform, vendor neutral management API for virtualzation. This is a huge step for F/LOSS over the total dominence of VMWare in this area.
I can see further use cases where providing a MinGW toolchain will benefit Fedora and F/LOSS. The FreeIPA project is providing state of the art authentication & directory services based on F/LOSS in Fedora, to rival the dominence of propriety ActiveDirectory services. This is already a huge step forward in a homogeneous environment of Linux servers and Linux desktops. Unless they can also support Windows desktops as clients though, it will forever be a niche player in the authentication/directory services arena. This is not good for F/LOSS or Fedora. A MinGW toolchain will facilitate the support of Windows clients and directly benefit the uptake of Fedora and F/LOSS in this area.
The current situation where people have to use VMWare for virt if they use Windows on the desktop does not provide an easy migration path to Fedora, because they have to replace both their management infrastructure and their desktop infrastructure at the same time. By providing a libvirt client enabled for Windows, we provide a viable migration path from a Windows world to a Fedora world. They can start off using Fedora for hosting their virtual machines, and as they discover the benefits of Fedora & F/LOSS they're more likely to also switch their desktop to Fedora.
So far from hijacking / sabotaging Fedora's principles, we're re-inforcing the value of Fedora and what it stands for and introducing it to a group of user who have never had any option to use it in the past.
Daniel
On Thu, Jul 10, 2008 at 2:26 AM, Daniel P. Berrange berrange@redhat.com wrote:
I can see further use cases where providing a MinGW toolchain will benefit Fedora and F/LOSS.
The question is.. what is the appropriate size of the "toolchain" that we provide as part of our distribution. If we stop at just getting MinGW into the distro as a useful tool...that's one thing.
But if we are then talking about allowing the use of MinGW or any other cross compiler in our build process to generate a full range of new packages and subpackages which contain windows DLLs variants of general purpose libraries contained in separate packages that can be installed on Fedora systems pulled from the Fedora repositories... that is something else entirely. I'm not sure this is something we want to allow in our build system nor in our packaging.
If we have a specific need to build windows executables, like migration aids or virtualization clients, then perhaps all of that should be done outside of our traditional build and packaging system, so that we are not pressured to rebuild and provide any and all libraries as Windows DLLs.
Let me sum up where I'm leaning as to a policy statement: * Building MinGW from sources as part of Fedora's repository offerings seems acceptable to me. I have no problem seeing cross compiler tools packaged as linux executables.
* Using MinGW to rebuild anything else, so that we can make Windows DLLs available in our base repository in binary packages..seems inappropriate and sets a bad precedent. How do we draw the line as to what library source (which is distinct from the MinGW sources) we allow or do not not rebuild and ship as DLLs? Paint me a bright line, because without a bright line the alternative is to allow all libraries to be rebuilt and packages as part of the repository in this way...and I just don't see how that is appropriate. I don't want to get suckered into a case by case basis where we weight the intended reason for making a certain library available as a DLL. If we have to weigh intent, then it should be done outside the repository. There's nothing stopping us from creating whatever sort of DLLs we need for Fedora Project window applications as part of our infrastructure project for specific application needs..outside of the build system meant to feed the general use repository.
*Having a 3rd party provide MinGW built library packages, and doing the work necessary to make sure the depresolving actually works with DLLs and EXEs rpm payloads seems very wise to me.
-jef
On Thu, Jul 10, 2008 at 02:20:29PM -0800, Jeff Spaleta wrote:
On Thu, Jul 10, 2008 at 2:26 AM, Daniel P. Berrange berrange@redhat.com wrote:
I can see further use cases where providing a MinGW toolchain will benefit Fedora and F/LOSS.
The question is.. what is the appropriate size of the "toolchain" that we provide as part of our distribution. [...]
Your argument seems to be that either just the MinGW compiler goes in, or everything in the world goes in, and there is no middle ground.
[...] Paint me a bright line,
OK, as with ordinary Fedora packages, a MinGW library would only go in if there was somebody willing to maintain it. It's highly unlikely that someone would be willing to maintain a MinGW cross-compile of every library currently in Fedora (it would certainly take all hours god gives and more to accomplish such a feat).
For libvirt the required libraries are:
- gnutls - libgcrypt - libgpg-error - libxml2 - portablexdr (*) - zlib
(*) not part of Fedora at the moment
and because having libvirt on Windows is a highly desirable outcome for us, we would be prepared to do the work either with maintainers, or ourselves, to maintain MinGW subpackages of these packages. If at some point in the future we aren't able to continue that work, then as with any other Fedora package they would eventually be removed from Fedora by standard processes.
The same would apply on a case-by-case basis to any other library.
I should stress again that this is no different from how Fedora packages currently get into and remain in Fedora: 'libbarquux' doesn't get into Fedora unless there is someone willing to maintain it, and if no one is willing to maintain it any more, then it becomes orphaned and eventually gets removed.
Rich.
On Sun, Jul 13, 2008 at 7:29 AM, Richard W.M. Jones rjones@redhat.com wrote:
and because having libvirt on Windows is a highly desirable outcome for us, we would be prepared to do the work either with maintainers, or ourselves, to maintain MinGW subpackages of these packages. If at some point in the future we aren't able to continue that work, then as with any other Fedora package they would eventually be removed from Fedora by standard processes.
The same would apply on a case-by-case basis to any other library.
I abhor case by case restrictions.. especially ones where we are trying to judge whether or not a single person as the time to actually maintain the package. We sure as hell don't do that for the rest of the packaging space. You have to do much better than "highly unlikely due to time commitment". I don't consider that a bright line at all. I need something as a policy statement which we block on at the time of package review.
And speaking of review... since you are doing this as a subpackage to existing packages we don't even have a requirement that this sort of thing goes through a peer review process because they aren't new packages. A bright line judgment process MUST involve peer review before... not after...the changes to the spec file are sitting in our cvs. I suggest you draft a policy statement as to how the review of mingw subpackages is suppose to work... and exactly what a reviewer is suppose to block on or how a reviewer is even suppose to test that the libraries work as expected.
What I still don't have an answer for is why does this need to be in the main repo? Why can't we spin off a mingw compiled repo as a separate addon repository inside our infrastructure? And then the minGW SIG can deal with library inclusions into that addon repo however they want..with their own submission and review policy..separate from the main repository policy.
I should stress again that this is no different from how Fedora packages currently get into and remain in Fedora: 'libbarquux' doesn't get into Fedora unless there is someone willing to maintain it, and if no one is willing to maintain it any more, then it becomes orphaned and eventually gets removed.
New packages go through a peer review step before we let them in. At a minimum mingw cross-compiled crap is going to need its own submission review..which isn't going to happen if we allow this in as subpackages because our existing review process doesn't extend to subpackage creation.
-jef
On Mon, Jul 14, 2008 at 07:39:40AM -0800, Jeff Spaleta wrote:
On Sun, Jul 13, 2008 at 7:29 AM, Richard W.M. Jones rjones@redhat.com wrote:
and because having libvirt on Windows is a highly desirable outcome for us, we would be prepared to do the work either with maintainers, or ourselves, to maintain MinGW subpackages of these packages. If at some point in the future we aren't able to continue that work, then as with any other Fedora package they would eventually be removed from Fedora by standard processes.
The same would apply on a case-by-case basis to any other library.
I abhor case by case restrictions.. especially ones where we are trying to judge whether or not a single person as the time to actually maintain the package. We sure as hell don't do that for the rest of the packaging space. You have to do much better than "highly unlikely due to time commitment". I don't consider that a bright line at all. I need something as a policy statement which we block on at the time of package review.
On the contrary, this is exactly how Fedora packaging works right now.
https://fedoraproject.org/wiki/Package_Review_Process "A Contributor is defined as someone who wants to submit (and maintain) a package in Fedora."
https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages "When Fedora maintainers do not want or are not able to maintain a package any longer, they can orphan or retire the package."
And speaking of review... since you are doing this as a subpackage to existing packages we don't even have a requirement that this sort of thing goes through a peer review process because they aren't new packages.
Well, with respect this is a problem with the Fedora process. Coming myself from a Debian background, I was always very surprised by the fact that once a package is in Fedora, it's virtually a free-for-all as to how that package is maintained. In Debian, things are quite different - large numbers of automated tests run continuously over existing packages, and any which don't conform to policy have an escalating scale of sanctions against them.
We can have a separate discussion about fixing the Fedora process.
What I still don't have an answer for is why does this need to be in the main repo? Why can't we spin off a mingw compiled repo as a separate addon repository inside our infrastructure? And then the minGW SIG can deal with library inclusions into that addon repo however they want..with their own submission and review policy..separate from the main repository policy.
Same could apply to, eg., Perl packages (no offence to perl maintainers :-). It is much more useful if these packages are part of Fedora, rather than unnecessarily cordoned off in a separate infrastructure.
New packages go through a peer review step before we let them in. At a minimum mingw cross-compiled crap is going to need its own submission review..which isn't going to happen if we allow this in as subpackages because our existing review process doesn't extend to subpackage creation.
With your use of phrases such as "mingw cross-compiled crap", I suggest you are not taking a level-headed approach to this. This is entirely free software, just that maybe it's not being used for purposes which you approve of. Fedora software is also used in the manufacture of tobacco products, cluster bombs and SUVs.
Rich.
Richard W.M. Jones wrote:
On Mon, Jul 14, 2008 at 07:39:40AM -0800, Jeff Spaleta wrote:
On Sun, Jul 13, 2008 at 7:29 AM, Richard W.M. Jones rjones@redhat.com wrote:
and because having libvirt on Windows is a highly desirable outcome for us, we would be prepared to do the work either with maintainers, or ourselves, to maintain MinGW subpackages of these packages. If at some point in the future we aren't able to continue that work, then as with any other Fedora package they would eventually be removed from Fedora by standard processes.
The same would apply on a case-by-case basis to any other library.
I abhor case by case restrictions.. especially ones where we are trying to judge whether or not a single person as the time to actually maintain the package. We sure as hell don't do that for the rest of the packaging space. You have to do much better than "highly unlikely due to time commitment". I don't consider that a bright line at all. I need something as a policy statement which we block on at the time of package review.
On the contrary, this is exactly how Fedora packaging works right now.
https://fedoraproject.org/wiki/Package_Review_Process "A Contributor is defined as someone who wants to submit (and maintain) a package in Fedora."
https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages "When Fedora maintainers do not want or are not able to maintain a package any longer, they can orphan or retire the package."
So are we talking subpackage or wholly new package for the mingw packages? These policies assume wholly new packages. I think that wholly new packages might be easier to manage in this respect.
And speaking of review... since you are doing this as a subpackage to existing packages we don't even have a requirement that this sort of thing goes through a peer review process because they aren't new packages.
Well, with respect this is a problem with the Fedora process. Coming myself from a Debian background, I was always very surprised by the fact that once a package is in Fedora, it's virtually a free-for-all as to how that package is maintained. In Debian, things are quite different - large numbers of automated tests run continuously over existing packages, and any which don't conform to policy have an escalating scale of sanctions against them.
We can have a separate discussion about fixing the Fedora process.
That would be very very nice.
What I still don't have an answer for is why does this need to be in the main repo? Why can't we spin off a mingw compiled repo as a separate addon repository inside our infrastructure? And then the minGW SIG can deal with library inclusions into that addon repo however they want..with their own submission and review policy..separate from the main repository policy.
Same could apply to, eg., Perl packages (no offence to perl maintainers :-). It is much more useful if these packages are part of Fedora, rather than unnecessarily cordoned off in a separate infrastructure.
This is a flase comparison, though. Perl packages allow end-user perl programs to run on Fedora. The proposals I see for mingw are aimed at allowing developers to work with building programs that will run on Windows. This is a big difference in focus.
OTOH, do we want to open the door to people running mingw-compiled binaries under wine? That seems like it might be a whole 'nother can of worms, though.
New packages go through a peer review step before we let them in. At a minimum mingw cross-compiled crap is going to need its own submission review..which isn't going to happen if we allow this in as subpackages because our existing review process doesn't extend to subpackage creation.
With your use of phrases such as "mingw cross-compiled crap", I suggest you are not taking a level-headed approach to this. This is entirely free software, just that maybe it's not being used for purposes which you approve of. Fedora software is also used in the manufacture of tobacco products, cluster bombs and SUVs.
Heh, from anyone else but Jef :-)
One question for you guys. Have you touched base with the Embedded SIG guys? (I saw Ralf replied to the packaging-list thread but nothing more official than that). They're doing work on cross compilers and seem to have more similarity to your work than most of the other models I've seen brought up here.
Looking at their wiki page, I also see that they have a stub entry for mingw:
https://fedoraproject.org/wiki/SIGs/Embedded
-Toshio
On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote:
OTOH, do we want to open the door to people running mingw-compiled binaries under wine? That seems like it might be a whole 'nother can of worms, though.
You can actually run the executables under wine directly. In fact you just run them. Assuming you've set up the ~/.wine/config file so that paths to any non-standard DLLs can be found, then ./virsh.exe does the right thing.
Setting up DLL paths correctly when mingw-runtime is installed was one thing I was going to look at.
One question for you guys. Have you touched base with the Embedded SIG guys? (I saw Ralf replied to the packaging-list thread but nothing more official than that). They're doing work on cross compilers and seem to have more similarity to your work than most of the other models I've seen brought up here.
Looking at their wiki page, I also see that they have a stub entry for mingw:
[To Ralf] Is there a mailing list for embedded work?
Rich.
Richard W.M. Jones wrote:
On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote:
OTOH, do we want to open the door to people running mingw-compiled binaries under wine? That seems like it might be a whole 'nother can of worms, though.
You can actually run the executables under wine directly. In fact you just run them. Assuming you've set up the ~/.wine/config file so that paths to any non-standard DLLs can be found, then ./virsh.exe does the right thing.
Yeah. I'm just wondering if widespread use of that would be a desirable or undesirable outcome. Here's a hypothetical:
Let's say that Google opensources Picasa. Do we want to build and run that Windows app under wine using a cross compiler or do we want to wait/start a project to port the program to native Linux APIs? I can see benefits to both sides.
Setting up DLL paths correctly when mingw-runtime is installed was one thing I was going to look at.
Cool.
-Toshio
On Mon, Jul 14, 2008 at 9:55 AM, Toshio Kuratomi a.badger@gmail.com wrote:
Yeah. I'm just wondering if widespread use of that would be a desirable or undesirable outcome. Here's a hypothetical:
Let's say that Google opensources Picasa. Do we want to build and run that Windows app under wine using a cross compiler or do we want to wait/start a project to port the program to native Linux APIs? I can see benefits to both sides.
I'm going to be deadly serious for a moment.
If it builds from source, then Fedora must demand that it does so natively as a precondition to consider building the binary that works under wine. The compiled binary version that works inside wine...would be optional if and only if the native version is up and available already. The native version must be available first in Fedora.
-jef
On Mon, Jul 14, 2008 at 7:30 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote:
OTOH, do we want to open the door to people running mingw-compiled binaries under wine? That seems like it might be a whole 'nother can of worms, though.
You can actually run the executables under wine directly. In fact you just run them. Assuming you've set up the ~/.wine/config file so that paths to any non-standard DLLs can be found, then ./virsh.exe does the right thing.
Setting up DLL paths correctly when mingw-runtime is installed was one thing I was going to look at.
If you can show a demo of compiling certain open source windows apps so that they can work on Fedora via wine, then I can definitely argue that this is no longer secondary architecture.
I have a couple of VJ programs some friends asked about getting into Fedora, all open source, but some run on windows. Being able to build them on Fedora easily will make it very easy for them to create a Fedora based VJ station.
Just my 0.02 USD.
-Yaakov
On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
If you can show a demo of compiling certain open source windows apps so that they can work on Fedora via wine, then I can definitely argue that this is no longer secondary architecture.
I have a couple of VJ programs some friends asked about getting into Fedora, all open source, but some run on windows. Being able to build them on Fedora easily will make it very easy for them to create a Fedora based VJ station.
I will fight you tooth and nail on this. It might even come down to a Dance Dance Revolution Dance off. If we can distribute it under the Fedora brand, we must have a version that runs natively before we consider a windows cross-compiled binary that runs under wine. I personally draw the line there. Native first, emulated second. If native doesnt work, get it fixed, or its not going to be part of Fedora.
-jef
On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
If you can show a demo of compiling certain open source windows apps so that they can work on Fedora via wine, then I can definitely argue that this is no longer secondary architecture.
I have a couple of VJ programs some friends asked about getting into Fedora, all open source, but some run on windows. Being able to build them on Fedora easily will make it very easy for them to create a Fedora based VJ station.
I will fight you tooth and nail on this. It might even come down to a Dance Dance Revolution Dance off. If we can distribute it under the Fedora brand, we must have a version that runs natively before we consider a windows cross-compiled binary that runs under wine. I personally draw the line there. Native first, emulated second. If native doesnt work, get it fixed, or its not going to be part of Fedora.
Frets on Fire.
Seriously, we might as well write the program over from scratch, cannabalizing the algorithms from it as we go along. Doing that would probably mean making a free-codec and nonfree-codec version too. Currently, it's supported by searching in all the usual windows places to see if codecs are installed.
Now that wine is 1.0, I think it really deserves the same pariah status that Mono should get. It's an API controlled by a single corporation that is not 100% documented, complex, and been reimplemented from the inside out. Where do we draw the line between Mono compiling EXEs and DLLs that work under .Net on Windows and a cross compiler compiling EXEs and DLLs that work on windows without .Net? If you really want to make this argument, why don't we draw the line at Mono?.
(Before anyone brings it up, Gstreamer's latency is too high for some of the things these guys are doing, which is a shame because it's just modular enough to make things like this less messy.)
-Yaakov
Yaakov Nemoy wrote:
On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
If you can show a demo of compiling certain open source windows apps so that they can work on Fedora via wine, then I can definitely argue that this is no longer secondary architecture.
I have a couple of VJ programs some friends asked about getting into Fedora, all open source, but some run on windows. Being able to build them on Fedora easily will make it very easy for them to create a Fedora based VJ station.
I will fight you tooth and nail on this. It might even come down to a Dance Dance Revolution Dance off. If we can distribute it under the Fedora brand, we must have a version that runs natively before we consider a windows cross-compiled binary that runs under wine. I personally draw the line there. Native first, emulated second. If native doesnt work, get it fixed, or its not going to be part of Fedora.
Frets on Fire.
Seriously, we might as well write the program over from scratch, cannabalizing the algorithms from it as we go along. Doing that would probably mean making a free-codec and nonfree-codec version too. Currently, it's supported by searching in all the usual windows places to see if codecs are installed.
Now that wine is 1.0, I think it really deserves the same pariah status that Mono should get. It's an API controlled by a single corporation that is not 100% documented, complex, and been reimplemented from the inside out. Where do we draw the line between Mono compiling EXEs and DLLs that work under .Net on Windows and a cross compiler compiling EXEs and DLLs that work on windows without .Net? If you really want to make this argument, why don't we draw the line at Mono?.
If I understand your question correctly, the big difference that I see is that .Net EXE's and DLLs (assemblies) run on any platform. AFAIK, windows .DLLs and .EXEs will only run on wine on x86.
-Toshio
On Mon, Jul 14, 2008 at 10:35 PM, Toshio Kuratomi a.badger@gmail.com wrote:
Yaakov Nemoy wrote:
On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
If you can show a demo of compiling certain open source windows apps so that they can work on Fedora via wine, then I can definitely argue that this is no longer secondary architecture.
I have a couple of VJ programs some friends asked about getting into Fedora, all open source, but some run on windows. Being able to build them on Fedora easily will make it very easy for them to create a Fedora based VJ station.
I will fight you tooth and nail on this. It might even come down to a Dance Dance Revolution Dance off. If we can distribute it under the Fedora brand, we must have a version that runs natively before we consider a windows cross-compiled binary that runs under wine. I personally draw the line there. Native first, emulated second. If native doesnt work, get it fixed, or its not going to be part of Fedora.
Frets on Fire.
Seriously, we might as well write the program over from scratch, cannabalizing the algorithms from it as we go along. Doing that would probably mean making a free-codec and nonfree-codec version too. Currently, it's supported by searching in all the usual windows places to see if codecs are installed.
Now that wine is 1.0, I think it really deserves the same pariah status that Mono should get. It's an API controlled by a single corporation that is not 100% documented, complex, and been reimplemented from the inside out. Where do we draw the line between Mono compiling EXEs and DLLs that work under .Net on Windows and a cross compiler compiling EXEs and DLLs that work on windows without .Net? If you really want to make this argument, why don't we draw the line at Mono?.
If I understand your question correctly, the big difference that I see is that .Net EXE's and DLLs (assemblies) run on any platform. AFAIK, windows .DLLs and .EXEs will only run on wine on x86.
Correction, .Net EXEs and DLLs will run on any platform only on top of .Net or Mono.
But otherwise yes.
True, we are limited to a single architecture, but then wine doesn't run on anything else, AFAIK, anyways.
-Yaakov
On Mon, Jul 14, 2008 at 12:44 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
Correction, .Net EXEs and DLLs will run on any platform only on top of .Net or Mono.
But otherwise yes.
True, we are limited to a single architecture, but then wine doesn't run on anything else, AFAIK, anyways.
And does mono run on the other arches?
-jef
On Mon, Jul 14, 2008 at 12:30 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
Now that wine is 1.0, I think it really deserves the same pariah status that Mono should get. It's an API controlled by a single corporation that is not 100% documented, complex, and been reimplemented from the inside out. Where do we draw the line between Mono compiling EXEs and DLLs that work under .Net on Windows and a cross compiler compiling EXEs and DLLs that work on windows without .Net? If you really want to make this argument, why don't we draw the line at Mono?.
Did you miss what happened in the runup to F9? We actually pulled pre-compiled stuff out of some mono packages...and it really pissed a few people off...but we did it.
-jef
On Mon, Jul 14, 2008 at 12:38:00PM -0800, Jeff Spaleta wrote:
On Mon, Jul 14, 2008 at 12:30 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
Now that wine is 1.0, I think it really deserves the same pariah status that Mono should get. It's an API controlled by a single corporation that is not 100% documented, complex, and been reimplemented from the inside out. Where do we draw the line between Mono compiling EXEs and DLLs that work under .Net on Windows and a cross compiler compiling EXEs and DLLs that work on windows without .Net? If you really want to make this argument, why don't we draw the line at Mono?.
Did you miss what happened in the runup to F9? We actually pulled pre-compiled stuff out of some mono packages...and it really pissed a few people off...but we did it.
But that was stuff where there either wasn't source or there was no clear chain from the source to the binary.
Please be clear that the MinGW cross-compiler is 100% free software built from source. If it turns out that any parts aren't, then they will be removed.
Rich.
On Mon, Jul 14, 2008 at 12:50 PM, Richard W.M. Jones rjones@redhat.com wrote:
But that was stuff where there either wasn't source or there was no clear chain from the source to the binary.
Please be clear that the MinGW cross-compiler is 100% free software built from source. If it turns out that any parts aren't, then they will be removed.
Sorry, I didn't mean to confuse the issue. I think Toshio is saying better what I am trying to say. There is a difference between cross-compiling code that is inherently arch-adependent in how its compiled and writing code in a language that is meant to be managed by a arch-independent virtual machine layer.
I have a very difficult time seeing wine as similar to any virtual machine based language such as mono unless wine can be built and run on multiple arches. So as such I would have a very hard time seeing any code be branded as Fedora that had to be run under wine to be useful at all. I'm okay with optionally building a varient that runs under wine as part of the Fedora project if and only if there is a native version of that code already available for Fedora Linux. if wine as a project gets to the point where it can usefully run on ppc, then i would feel a lot better letting application code inside Fedora need it. But I'd still want to have it as a side-repo.
-jef
On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote:
So are we talking subpackage or wholly new package for the mingw packages? These policies assume wholly new packages. I think that wholly new packages might be easier to manage in this respect.
Four packages are mingw-specific. They are:
mingw-runtime Runtime libs mingw-binutils Binutils tools mingw-gcc GCC cross-compiler mingw-w32api Win32 API header files
However these alone are not really useful, because if you want to compile anything which isn't just a bare C program, you'll be needing dependent libraries too.
How libraries are packaged is an open issue.
Libraries are compiled from the latest source. Usually it's just a matter of doing %configure --host=i686-pc-mingw32 but of course because these libraries aren't routinely compiled for MinGW by upstream, I expect there will be a lot more bugs/regressions which the maintainer will need to handle.
Taking GnuTLS purely as an example ...
Dan Berrange wanted libraries to be built as a subpackage of existing libraries. Thus we'd have a subpackage of the current Fedora gnutls package. I have shown how this would work here:
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00435.html http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=91a8...
The advantage is that we stay in step with upstream GnuTLS, including things like bug/security fixes. Also we're building from a single SRPM which is possibly more efficient.
The disadvantages include the fact that the library maintainer may not be interested in maintaining the mingw subpackage, it's the first thing that'll be turned off when problems arise, no Fedora review, ..
We can also do libraries as independent packages. For example, for GnuTLS I did this independent package:
http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=2b4ca8a081d8;file=gnutls...
My opinion would be to allow _both_ approaches, depending on what the existing Fedora maintainer of a library was happy doing.
Rich.
On Mon, Jul 14, 2008 at 9:25 AM, Toshio Kuratomi a.badger@gmail.com wrote:
OTOH, do we want to open the door to people running mingw-compiled binaries under wine? That seems like it might be a whole 'nother can of worms, though.
All the more reason to move ALL mingw compiled dlls into a separate repo tree. If its got libraries and applications.. its almost a completely separate distribution in and of itself.
And I'm okay with that, but let's set it up that way from the beginning so it can grow into that sort of potential smoothly.
-jef
On Mon, Jul 14, 2008 at 09:54:06AM -0800, Jeff Spaleta wrote:
All the more reason to move ALL mingw compiled dlls into a separate repo tree. If its got libraries and applications.. its almost a completely separate distribution in and of itself.
I think I don't understand what you mean by a separate Fedora repository. Do you mean as in the way that 'sources', 'debuginfo' and 'updates' are separate? How would I go about requesting such a repo?
- -
You mentioned the similarity to secondary archs in your other email. Obviously this does sort of look like a secondary arch, but I think there are significant differences -- eg. this work isn't self-hosting, unless you involve an actual Windows host (or perhaps some really complicated Wine configuration??)
Rich.
On Mon, Jul 14, 2008 at 9:55 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Jul 14, 2008 at 09:54:06AM -0800, Jeff Spaleta wrote:
All the more reason to move ALL mingw compiled dlls into a separate repo tree. If its got libraries and applications.. its almost a completely separate distribution in and of itself.
I think I don't understand what you mean by a separate Fedora repository. Do you mean as in the way that 'sources', 'debuginfo' and 'updates' are separate? How would I go about requesting such a repo?
We don't know yet...cross compiling is new. So we need to figure out how best to support it.
You mentioned the similarity to secondary archs in your other email. Obviously this does sort of look like a secondary arch, but I think there are significant differences -- eg. this work isn't self-hosting, unless you involve an actual Windows host (or perhaps some really complicated Wine configuration??)
Right its not completely self-hosting. Everything about cross-compiling is wonky. Its mixes things up. But basically..for the purposes of my strawman. we'd set up a virtual arch in our build system, but when building in our build system for it pulls from the i386 tree as its build environment. Someone needs to tell me if this is possible to do through nested arch definitions.
So for the sake of argument, can we teach rpm to understand an arch called "mingw-ix86" such that it inherits the ix86 packages? We then construct a build environment definition in mock which includes the mingw-ix86 and ix86 branches that will run on ix86 hardware and compile the mingw dll subpackages which are ifarch conditioned?
I would need a more technical person to tell me how bad my strawman is. And yes I realize, its going to take some amount of technical work to do. And yes..I know I'm not the one who is going to be doing it. But I think we need to get this right and make a space for this sort of cross-compiled content in a way that lets it grow organically. I just don't think we can do that if we shove these payloads into the main tree.
-jef
On Mon, Jul 14, 2008 at 10:15:58AM -0800, Jeff Spaleta wrote:
So for the sake of argument, can we teach rpm to understand an arch called "mingw-ix86" such that it inherits the ix86 packages? We then construct a build environment definition in mock which includes the mingw-ix86 and ix86 branches that will run on ix86 hardware and compile the mingw dll subpackages which are ifarch conditioned?
Jeff, you're not offering anything constructive here. There's talk of mysterious extra repositories, and invasive changes to RPM & mock, but I'm no closer to understanding what purpose this achieves, or indeed _how_ to achieve it.
I've presented a plan which involves adding 4 base packages to Fedora (already built[*]) and some number of additional packages for libraries (where 'some number' is approximately 7, also already built[*]). And I've found people who are willing to maintain these packages in the long term.
Now, it's not perfect -- there are some things we need to resolve such as the precise naming convention and how to stop the strip command from damaging DLLs -- but it is nevertheless a plan that one can see how to finish. It doesn't violate any existing Fedora policy that I can see, and I've even provided my arguments that it increases the overall value of Fedora.
So unless you wish to provide a detailed plan -- not hand-wavey stuff about Fedora providing 'extra infrastructure' or 'teaching RPM to understand' things -- I really don't think I can sensibly continue this discussion.
Rich.
[*] http://hg.et.redhat.com/misc/fedora-mingw--devel/
On Mon, Jul 14, 2008 at 2:57 PM, Richard W.M. Jones rjones@redhat.com wrote:
So unless you wish to provide a detailed plan -- not hand-wavey stuff about Fedora providing 'extra infrastructure' or 'teaching RPM to understand' things -- I really don't think I can sensibly continue this discussion.
I plan to talk to more people about whether we can set this up in the same was as a secondary arch works. Failing that however... running this as an addon repo is possible with known technical knowledge. EPEL is an existing implementation of an addon repository... it just doesn't target Fedora as its base repo. But we certainly know how to do an addon repo this way that does not invoke any new tricks.
The question main question remains, what's a reasonable way to handle the inclusion of cross-compiled libraries into the project. I don't think I've seen consensus expressed. There is a consensus that the immediate aim of building libvirt related cross compiled libraries has significant value, but its not clear what we want to do beyond that.
If we end up deciding that the dlls are generally not appropriate in the main repository (and that is something I plan to discuss more at tomorrow's board meeting) than we can certainly implement the technical details to open a mingw addon repo constructed like EPEL.. if we want to allow it at all.
We don't have existing policy with regard to cross-compiling because its a new capability with the introduction of the mingw tool into are distro. But just because the tool exists, does not mean packaging and distributing binaries built with it makes sense for the distribution nor for the project in a broader sense. I would hope that no subpackages with mingw built payloads will find their way into rawhide until we have a defensible policy statement in place that sets the bounds on what we really want to see that we can point to as more people look to replicate what you are doing with the libvirt libraries. Holding off on their introduction, will suck marginally less than if we put a handful of libs in and then the 6 months from now we end up deciding on a policy which does not allow them in at all.
-jef
On Mon, Jul 14, 2008 at 7:50 AM, Richard W.M. Jones rjones@redhat.com wrote:
With your use of phrases such as "mingw cross-compiled crap", I
I have to apologize.. i use the word "crap" quite liberally as a synonym for "stuff". I need to stop doing that. Just wanted to say that first.
On the contrary, this is exactly how Fedora packaging works right now.
https://fedoraproject.org/wiki/Package_Review_Process "A Contributor is defined as someone who wants to submit (and maintain) a package in Fedora."
https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages "When Fedora maintainers do not want or are not able to maintain a package any longer, they can orphan or retire the package."
All of these definitions speak to my original concern. If we let you package up mingw built libraries.. there is nothing in our policy which would keep any one else from doing exactly the same with other libraries. The "highly unlikely" argument doesn't hold water. There is no bright line between you or any other contributor. If you can add a subpackage.. then anyone else can..and we could quite easily in 2 releases end up with a large collection of cross-compiled paylods in the main repository..that we expect all our mirrors to digest. I'd rather plan for that sort of future, instead of pretending that you and a few other contributors are special compared to other library maintainers. If you can't stand up a reason any better than "most package maintainers won't be able to do it" then I have to assume that other library maintainers will do it, because you will enable them to do it. The stuff that is being drafted right now for the mingw SIG is going to lower the bar significantly for the next group of maintainers who want to get a dll compiled.
Well, with respect this is a problem with the Fedora process. Coming myself from a Debian background, I was always very surprised by the fact that once a package is in Fedora, it's virtually a free-for-all as to how that package is maintained. In Debian, things are quite different - large numbers of automated tests run continuously over existing packages, and any which don't conform to policy have an escalating scale of sanctions against them.
We can have a separate discussion about fixing the Fedora process.
No we are going to have a discussion in the context of dealing with cross-compiled content. You have to present how you expect cross-compiled content to be reviewed for submission or I'm going to push back really hard, harder than I am right now, about seeing any cross-compiled content into the main repository. This stuff is so different than are regular workflow, that it requires some care concerning how to fit in the review into our existence submission and review model. These are exactly the sort of questions I expect the mingw SIG to have some initial answers for. You can't just throw a few of these subpackages over the wall and call the work of the SIG done. You must, you absolutely must propose how these things are to be reviewed.
Same could apply to, eg., Perl packages (no offence to perl maintainers :-). It is much more useful if these packages are part of Fedora, rather than unnecessarily cordoned off in a separate infrastructure.
Are you saying that enabling an additional repository in your package manager is in fact too burdensome for a developer who is looking to cross-compile? C'mon.
I don't understand why its much more useful in the main repo. The repo definition would exist in the default configs and it could either be enabled or disable by default. Hell you could enable it by default in the developer spin, but disable it by default in the Desktop spin. Isn't the target market for this stuff developers? The point however is that we do not demand that all the main mirrors host this material. They would be given a choice to pick this up and if you are wrong and this becomes popular and a lot of people want to rebuild libraries against mingw..we will have the structure in place to support it without burdening the main repository with 2x the library binaries.
Stop dogging the question by holding up other sorts of payloads as strawmen. If you continue to do that, I'm going to stop asking the question hoping for a defensable answer.
First..these mingw libraries do not directly benefit Fedora users. Perl, python, native libraries are directly provided to be used as part of the users of the Fedora Linux distribution. There is a clear distinction between what we provide currently and anything that is cross-compiled.
Yes the mingw compiled dlls are useful to a subset of developers. I'm not questioning that. But I am less and less sure that the value there is worth opening up the main repository to this sort of cross-compiled content. And I am becoming more sure that the value that is there is maximized by having an expansive set of such dlls.. not limited to the immediate needs of libvirt. By setting this up as a separate repo but still inside the Fedora project, we can move forward and give you want you need but also start a process by which we can maximize the community value of these builds. In a lot of ways, this would almost be its own distribution that was built on Fedora.
Second..we don't even ship all possible arches of the libraries that we do have. We have this concept called secondary arches so that individual contributors who want to extend Fedora onto new hardware platforms can do so, by bring resources to the table to do it, without asking the main mirrors to take on the distribution of that additional compiled material. A collection mingw compiled dlls feels very much like a cross between a distribution and secondary arch. Which sort of makes sense..since we are talking about cross-comppiling.
Why shouldn't we ask you or anyone else who wants to cross-compile for another platform to be treated similarly from a policy perspective to how we ask our secondary arch developers to be treated? Why can't we make mingw a virtualized arch, and ask that the mingw payloads be ifarch'd in the spec file and built only for a specific arch target so that it can be treated as a secondary arch for a hosting and distribution point of view?
Would you call secondary arches like sparc or arm "cordoned off" in our current policy.
You aren't going to dodge the review burden on mingw payloads by waving your hands and saying the Fedora process is broken. If you feel our process needs fixing, then we fix it first before the mingw payloads are allowed in... not the other way around.
-jef
On Jul 9, 2008, Richard Jones rich@annexia.org wrote:
almost nobody (perhaps 10, 100 people in the whole world?) are running a completely free operating system (inc. BIOS etc).
Err... When did BIOS become part of the operating system? :-)
On Sun, Jul 13, 2008 at 05:19:03PM -0300, Alexandre Oliva wrote:
On Jul 9, 2008, Richard Jones rich@annexia.org wrote:
almost nobody (perhaps 10, 100 people in the whole world?) are running a completely free operating system (inc. BIOS etc).
Err... When did BIOS become part of the operating system? :-)
Heh, since CP/M of course. You're one of the 100 people :-)
Rich.
Axel Thimm wrote:
On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote:
What is Fedora's motivation is promoting using Open Source on a closed source operating system?
Imo, motives don't matter here. If it's license-wise (and otherwise policy-wise) ok with fedora, then end of story.
-- Rex
On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote:
What is Fedora's motivation is promoting using Open Source on a closed source operating system? This is beyond the FPC to decide as this is a technical committee, but still a valid question and maybe one that the board should be investigating.
F/LOSS often had and has to compromise on its base principles to get a lift-off, and so does Fedora (the current exception for firmwares is such a compromise). Before there was a Linux kernel, the GNU project was "supporting" closed source Unices and by design still does so.
But we're beyond the age of this kind of symbiosis, Linux (or GNU/Linux ...) and Fedora in particular doesn't need this anymore. In fact when a patch in a Fedora package is made it often doesn't matter if it works on other Unices, sometimes not even for the Free ones.
<rhetorical> If we're beyond the age of symbiosis, we can remove SAMBA from Fedora then, because that's only needed for interoperability with closed source products. </rhetorical>
I'd love to believe that Fedora and F/LOSS had achieved world domination but sadly we're still fighting the battle, though unquestionably further along than we were just a few years ago. One of the best things about F/LOSS is that there are soo many projects breaking down proprietry walled gardens, but providing interoperability with closed source produts/platforms. This is providing users an escape path, allowing them to migrate to Fedora.
SAMBA is a great example of this. We want Fedora+libvirt to provide the escape path for people running VMWare + Windows, and for this to work we need to provide the libirt clients for Windows platforms. This enables them to switch out VMWare in favour of Fedora + Xen/KVM, without having to migrate their entire desktop environment from Windows to Linux at the same time.
Daniel
On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote:
What is Fedora's motivation is promoting using Open Source on a closed source operating system?
Thanks all for enlightening this. Jeff Spaleta more or less outlined the background thoughts I was having about it - envisioning building all of our fruits for consumption on the enemy territory was a bit scary.
Daniel Berrange and Richard Jones explained the libvirt background which more than justifies this move, thanks for explaining.
But what I'd like to still see addressed is whether there will be a policy of what other tools/apps are acceptable for Fedora. mingw, libvirt etc. do have their justification as a means to an end, but what happens when Joe Random Packager discovers the mingw package and thinks this is an invitation to rebuild all of Fedora for Windows (where possible) and submit as a new package? Do we want this? If not how do we prevent this or communicate it properly to the packager base?
On Thu, Jul 10, 2008 at 1:23 PM, Axel Thimm Axel.Thimm@atrpms.net wrote:
But what I'd like to still see addressed is whether there will be a policy of what other tools/apps are acceptable for Fedora. mingw, libvirt etc. do have their justification as a means to an end, but what happens when Joe Random Packager discovers the mingw package and thinks this is an invitation to rebuild all of Fedora for Windows (where possible) and submit as a new package? Do we want this? If not how do we prevent this or communicate it properly to the packager base?
So basically the question is.. how much of our existing set of software is appropriate to rebuild with the mingw chain and make available as binary packages in the project itself in the form of packages? If I'm following the technical discussion correctly.. then we are talking about packaging some set library binaries meant to be used with mingw. It's not just about making mingw available as a tool..but its also about building some library binaries with mingw and packaging them as part of Fedora as part of a mingw development environment. Or am I wrong about that?
For the sake of this discussion lets just limit ourselves to libraries and development packages..that's still a big space.
How many libraries should we rebuild and package as part of a functional mingw development environment as windows DLL? Is it appropriate to rebuild all of our libraries such that they can be used with mingw? Saving people the necessary effort to rebuild the libraries themselves?
Is this really an appropriate use of our Project mirroring and repository resources? How much bigger would the repository end up being if all our existing libraries were repackaged as windows DLLs? Is that potential resource burn worth the trade off of making it turnkey for people to mingw to build windows executables on Fedora?
The base package definitions at http://fedoraproject.org/wiki/PackagingDrafts/MinGW may make obvious sense as a way to get the mingw tool into the distribution. But do the concepts of packaging Windows DLL and Windows EXEs make sense for us? Do we want to be distributing a full range of Windows DLLs and Windows EXEs in our repository? Or do we want to distribute the absolute minimum set of base packages to get mingw into the hands of users and let them rebuild the DLLs they need from source?
I'm not sure I'm okay with rebuilding our entire collection of libraries as Windows DLLs and packaging them as part of our distribution, taking up project repository and mirror space.
-jef
I would just like to direct people on the fedora-advisory-board list to my previous reply here, which should address all of Jeff's questions:
https://www.redhat.com/archives/fedora-packaging/2008-July/msg00043.html
except for this one:
On Thu, Jul 10, 2008 at 01:53:18PM -0800, Jeff Spaleta wrote:
Is this really an appropriate use of our Project mirroring and repository resources? How much bigger would the repository end up being if all our existing libraries were repackaged as windows DLLs?
Leaving aside the fact that it's completely unrealistic to think anyone could recompile every Fedora library, and no one is proposing to do this anyway (see my answer above), I do have some figures on how big the MinGW RPMs are on my (32 bit) machine compared to the ordinary Fedora RPMs [0]:
4.1M mingw-libxml2-2.6.32-1.fc10.i386.rpm
847K libxml2-2.6.32-3.fc10.i386.rpm 1.4M libxml2-devel-2.6.32-3.fc10.i386.rpm
108K mingw-zlib-1.2.3-1.fc10.i386.rpm
75K zlib-1.2.3-18.fc9.i386.rpm 43K zlib-devel-1.2.3-18.fc9.i386.rpm
3.3M mingw-gnutls-2.4.1-2.fc10.i386.rpm
390K gnutls-2.4.1-2.fc10.i386.rpm 2.5M gnutls-devel-2.4.1-2.fc10.i386.rpm 128K gnutls-utils-2.4.1-2.fc10.i386.rpm [1]
If we carry out a plan of building from the same SRPM then there shouldn't be any significant increase there. There are no debuginfo packages for MinGW.
Rich.
[0] Note that there is no foo / foo-devel split in the mingw packages.
[1] Windows utilities (certtool.exe etc) are included in the mingw-gnutls package at present.
On Fri, Jul 11, 2008 at 12:23:52AM +0300, Axel Thimm wrote:
but what happens when Joe Random Packager discovers the mingw package and thinks this is an invitation to rebuild all of Fedora for Windows (where possible) and submit as a new package? Do we want this? If not how do we prevent this or communicate it properly to the packager base?
Joe Random would certainly have a lot of time on his hands to do this.
MinGW cross-compiles are *not* straightforward, and will require a great deal of care and maintenance, dealing with upstream to fix newly introduced bugs and so on. As with other Fedora packages, they only go in if someone is willing to maintain them, and come out if no one is willing to continue maintaining them.
Rich.
On Sun, Jul 13, 2008 at 04:34:01PM +0100, Richard W.M. Jones wrote:
On Fri, Jul 11, 2008 at 12:23:52AM +0300, Axel Thimm wrote:
but what happens when Joe Random Packager discovers the mingw package and thinks this is an invitation to rebuild all of Fedora for Windows (where possible) and submit as a new package? Do we want this? If not how do we prevent this or communicate it properly to the packager base?
Joe Random would certainly have a lot of time on his hands to do this.
MinGW cross-compiles are *not* straightforward, and will require a great deal of care and maintenance, dealing with upstream to fix newly introduced bugs and so on. As with other Fedora packages, they only go in if someone is willing to maintain them, and come out if no one is willing to continue maintaining them.
Hi,
Joe Random's (in)finite time resources and (in)finite reviewing pals are not the problem, I'm not addressing this from a technical/organisational POV, but from principles.
Just to present a real life example: I was arguing on the merits of having Fedora at schools as it comes with openoffice, gimp and so on, and a teacher took out a portable drive with portableapps.com and demostrated that he already has all of this on Windows now. And indeed the systems are now still running Windows ...
So, when Joe Random starts preparing to use Fedora as a platform for building gimp or some other interesting F/LOSS bits for a proprietary system that is harming Fedora *Linux* are we really open to this?
Maybe we are, I'm just posing the question. Maybe Fedora is about promoting free/open software in general whether that runs on a Linux kernel or whether that runs on *BSD, a proprieray Unix/Windows system etc. Maybe its is narrowing down to promoting fuller F/LOSS solutions including the OS, e.g. Linux and *BSD. Or it is (what I thought until now) a Linux based F/LOSS model (which doesn't preclude good relation with *BSD camps, or willing to help people on the Windows side of the earth to make the step to Linux).
I think this is a rephrasing of Jeff's brigth line that he seeks to draw and wants to know what it will include and what not.
So the issue is a political one, not a technical one. Supporting libvirt for running Fedora under Windows is one thing, supporting increased productivity on Windows another. Personally I would discourage the second model, or at least outsource it away from the Fedora brand. And we should decide on it now, that mingw is entering Fedora, rather than dealing with it when the Joe Randoms come in.
Just to trigger some related thoughts: I wonder what would happen if someone submitted a cross-compiler and cross-built libs/tools for SCO Unix. Would we lay back and discuss it on technical points and whether there are enough maintainers etc?
On Sun, Jul 13, 2008 at 07:30:12PM +0300, Axel Thimm wrote:
So, when Joe Random starts preparing to use Fedora as a platform for building gimp or some other interesting F/LOSS bits for a proprietary system that is harming Fedora *Linux* are we really open to this?
It's not at all clear that being able to build Gimp (as an example) is harming Fedora.
There are at least three cases:
(1) User switches from Photoshop to Gimp (and other free apps) and eventually, much later asks themselves 'why am I bothering to pay for this Windows stuff when Linux runs all the same apps I'm now using?' and they are then able to easily switch to Linux.
(2) User switches from Photoshop to Gimp, but continues using Windows forever because they simply prefer the 'Start' menu and other Windows desktop features.
(3) Because the fedora-packaging mailing list has successfully prevented any free apps from being available for Windows, user is forced to switch their entire system (all their apps, operating system, document formats) all at once from proprietary to free.
Which is likely to happen? No idea. You could, I guess, devise a study to see what typical users do.
Rich.
On Sun, Jul 13, 2008 at 09:10:46PM +0100, Richard W.M. Jones wrote:
On Sun, Jul 13, 2008 at 07:30:12PM +0300, Axel Thimm wrote:
So, when Joe Random starts preparing to use Fedora as a platform for building gimp or some other interesting F/LOSS bits for a proprietary system that is harming Fedora *Linux* are we really open to this?
It's not at all clear that being able to build Gimp (as an example) is harming Fedora.
There are at least three cases:
(1) User switches from Photoshop to Gimp (and other free apps) and eventually, much later asks themselves 'why am I bothering to pay for this Windows stuff when Linux runs all the same apps I'm now using?' and they are then able to easily switch to Linux.
Does this include the typical user that had a proprietary OS preinstalled (and prepaid whether he liked it or not) on his system, or does he propably not care now to make the switch since his needs are fulfilled? And any other user that had a legitimate Windows license is in great pain to even sell it if he's allowed to at all.
(2) User switches from Photoshop to Gimp, but continues using Windows forever because they simply prefer the 'Start' menu and other Windows desktop features.
(3) Because the fedora-packaging mailing list has successfully prevented any free apps from being available for Windows, user is forced to switch their entire system (all their apps, operating system, document formats) all at once from proprietary to free.
I thought the libvirt on Windows project was there to create a middle-step for this, or not?
Which is likely to happen? No idea. You could, I guess, devise a study to see what typical users do.
Please check my full post, it actually contained a recent real life example from a school that was about to switch to Fedora until it was discovered that one can use gimp and other free software on Windows XP. And if it counts as a study, I certainly did have the argument of Windows vs Linux about a million times, and I'm sure everyone on this list and his cat had it as well. We don't really need a study on the oldest question in the Computer Age. ;)
Very few people run Windows for the pleasure of it - applications, be that an Office suite, graphics, internet, and even games define the true stack.
On Jul 13, 2008, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So the issue is a political one, not a technical one. Supporting libvirt for running Fedora under Windows is one thing, supporting increased productivity on Windows another.
FTR, if we were to pursue the latter, I think it might make more sense, at least from my perception of Red Hat's perspective, to join forces with Cygwin, maybe even bring it into the Fedora brand/umbrella.
https://fedoraproject.org/wiki/PackagingDrafts/MinGW
I'd like to get this discussed at FPC next Tuesday. If anyone has any technical points on the draft, can you let me know or edit the page.
(I've taken on board Ralf's point about mingw vs mingw32, although I'm not sure what is the correct course of action at the moment ...)
Rich.
On Thursday, 10 July 2008 at 12:44, Richard W.M. Jones wrote:
https://fedoraproject.org/wiki/PackagingDrafts/MinGW
I'd like to get this discussed at FPC next Tuesday. If anyone has any technical points on the draft, can you let me know or edit the page.
(I've taken on board Ralf's point about mingw vs mingw32, although I'm not sure what is the correct course of action at the moment ...)
Looks mostly fine to me, although I don't like the length of %{_prefix}/i686-pc-mingw32/sys-root/mingw Could this be shortened to, say, %{_prefix}/i686-pc-mingw32/(sys)root/ ? Are there going to be any files in %{_prefix}/i686-pc-mingw32/sys-root that you need the additional /mingw there?
Regards, R.
On Thu, 2008-07-10 at 21:50 +0200, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 10 July 2008 at 12:44, Richard W.M. Jones wrote:
https://fedoraproject.org/wiki/PackagingDrafts/MinGW
I'd like to get this discussed at FPC next Tuesday. If anyone has any technical points on the draft, can you let me know or edit the page.
(I've taken on board Ralf's point about mingw vs mingw32, although I'm not sure what is the correct course of action at the moment ...)
Looks mostly fine to me, although I don't like the length of %{_prefix}/i686-pc-mingw32/sys-root/mingw Could this be shortened to, say, %{_prefix}/i686-pc-mingw32/(sys)root/ ?
No.
.../sys-root/ is a foreign system's mapping onto the host system, i.e. what is "/" under a native MinGW is /usr/i686-pc-ming32/sys-root/ under Fedora.
The "mingw" directory in ../sys-root/mingw is the standard directory mingw uses natively to install in Windows and can't easily be remove.
Are there going to be any files in %{_prefix}/i686-pc-mingw32/sys-root that you need the additional /mingw there?
Hardly, but ... that's how things are supposed to be installed ;)
You could network mount this mingw/-directory under Windows, should this be possible :)
Ralf
On Friday, 11 July 2008 at 12:27, Ralf Corsepius wrote: [...]
OK, thanks for the explanations. I don't have any more technical issues right now.
Regards, R.
On Thu, Jul 10, 2008 at 11:44:54AM +0100, Richard W.M. Jones wrote:
https://fedoraproject.org/wiki/PackagingDrafts/MinGW
I'd like to get this discussed at FPC next Tuesday. If anyone has any technical points on the draft, can you let me know or edit the page.
Unfortunately I'm double-booked so I can't be at the meeting today.
Also these packages really need more work on them before presenting them to FPC.
So I'll punt until +2 weeks.
Rich.
Richard W.M. Jones wrote:
On Thu, Jul 10, 2008 at 11:44:54AM +0100, Richard W.M. Jones wrote:
https://fedoraproject.org/wiki/PackagingDrafts/MinGW
I'd like to get this discussed at FPC next Tuesday. If anyone has any technical points on the draft, can you let me know or edit the page.
Unfortunately I'm double-booked so I can't be at the meeting today.
Also these packages really need more work on them before presenting them to FPC.
So I'll punt until +2 weeks.
We didn't have enough people for quorum this week. We'll hold a meeting next week (July 22) to see if we can get quorum to pass things.
We did a little talking about cross compiling in general at our meeting. Those who were there thought that having a separate source rpm per-package-per-library makes more sense than subpackages (likely different maintainers, having to maintain two sets of build instructions in the spec, some cross-compilers require more invasive changes, and simply not scaling in a general way when we have multiple cross-compilers.)
I'll note that neither Hans nor Ralf were present (both on the embedded SIG) and their input could definitely change this but the present thinking is that separate packages are the way to go.
-Toshio
packaging@lists.fedoraproject.org
-
Alexandre Oliva -
Anthony Green -
Axel Thimm -
Daniel P. Berrange -
Dominik 'Rathann' Mierzejewski -
Jef Spaleta -
Ralf Corsepius -
Rex Dieter -
Richard Jones -
Richard W.M. Jones -
Stephen John Smoogen -
Toshio Kuratomi -
Yaakov Nemoy