supporting closed source operating systems?

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=91a808c59de63589367c7bd9750 da1fca342c529;path=/gnutls-fragment/

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/mingw-gnutls.spec

My opinion would be to allow _both_ approaches, depending on what the
existing Fedora maintainer of a library was happy doing.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Sun, 2008-07-13 at 19:30 +0300, Axel Thimm wrote:

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

Thanks for this post, for me it did a good job of separating the
technical from $other considerations.

The Fedora brand is a Linux brand. It makes sense to have some
Microsoft Windows stuff where it supports that story, such as tools to
assist migration ... to Linux. The libvirt pieces seem, to me, to be a
good enough fit and belong on this side of the bright line.

But we need to make it clear that we are not going to morph Fedora into
being some super-meta-FLOSS thing. So, to me, the productivity apps
belong on the other side of the bright line. If we want to be involved
in helping people switch from Microsoft Windows by supporting
productivity FLOSS stacks that runs on that OS, it should be under a
brand other than Fedora. Such as "Mozilla". ;-D

- Karsten
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Mon, 2008-07-14 at 12:48 -0700, Karsten 'quaid' Wade wrote:
> On Sun, 2008-07-13 at 19:30 +0300, Axel Thimm wrote:
>
> > 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.
>
> Thanks for this post, for me it did a good job of separating the
> technical from $other considerations.
>
> The Fedora brand is a Linux brand. It makes sense to have some
> Microsoft Windows stuff where it supports that story, such as tools to
> assist migration ... to Linux. The libvirt pieces seem, to me, to be a
> good enough fit and belong on this side of the bright line.
>
> But we need to make it clear that we are not going to morph Fedora into
> being some super-meta-FLOSS thing. So, to me, the productivity apps
> belong on the other side of the bright line. If we want to be involved
> in helping people switch from Microsoft Windows by supporting
> productivity FLOSS stacks that runs on that OS, it should be under a
> brand other than Fedora. Such as "Mozilla". ;-D
>

Thanks Karsten. I agree with the above.

-sv




_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, Jul 14, 2008 at 11:48 AM, Karsten 'quaid' Wade <kwade@redhat.com> wrote:
> The Fedora brand is a Linux brand. It makes sense to have some
> Microsoft Windows stuff where it supports that story, such as tools to
> assist migration ... to Linux. The libvirt pieces seem, to me, to be a
> good enough fit and belong on this side of the bright line.

Even if you want to draw the line based on intent in the language of
cohesive branding...and you want to say that compared to the possible
community needs for cross-development..the libvirt needs enhance the
value of the brand in a way that other cross-development needs in the
community do not....I'm still not sure this needs to be in the main
repository of the distribution.

We can brand it Fedora and it can live outside the main repo. I do not
want to have to defend a special case for mingw cross-compiled stuff
specifically on the basis that it is good for libvirt development on
Windows and exclude all the other possible cross-development needs
which the community will think up once they have access mingw as part
of our distribution. And they will think them up. If we are going to
special case it, lets special case it outside the main Fedora linux
distribution repository and set this up as Fedora branded addon
repository targeting libvirt on windows specifically.

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board