supporting closed source operating systems?

On Thu, 2008-07-10 at 13:53 -0800, Jeff Spaleta wrote:

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

Aside from the secondary arch precedent, there are the precedents of
EPEL and OLPC. There is a strong relationship between Fedora and RHEL,
but packages from one don't necessarily run on the other.

The difference in these cases is that we can emulate/virtualize
environments from within Fedora to run e.g. RHEL and OLPC (Sugar), all
from 100% FLOSS. The same is may not be true of DLLs and EXEs from
MinGW. Maybe some runs under WINE, or Cygwin. But all? Seems
unlikely.

I am only pointing out the precedents and differences in this case, I've
no idea yet if we are in danger of slipping down a slope.

- 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 Thu, Jul 10, 2008 at 4:26 PM, Karsten 'quaid' Wade <kwade@redhat.com> wrote:
> I am only pointing out the precedents and differences in this case, I've
> no idea yet if we are in danger of slipping down a slope.

I haven't seen anyone put forward any rationale by which to limit
which libraries we distribute compiled against mingw. The libraries
so far suggested are specifically targeted so libvirt can be more
easily developed. But there's no bright line painted as to why we
should not allow all libraries to be rebuild and packaged if people
desire them. If we let the relatively narrow set of libraries be
rebuilt for the virtualization development needs as part of our
repository, then we are opening the door for all libraries to be
rebuild and packaged. I haven't seen a credible argument to limit
mingw rebuilds to just what libvirt needs. And quite frankly we
shouldn't be setting limits on intended use. If we allow any mingw
built libraries into a repository we control.. then we should let all
libraries be rebuilt with mingw. We should not get into the business
of trying to determine if one sort of development need for a library
is more worthwhile than any other. So if we let in what libvirt needs
rebuilt in mingw, I'm pretty sure we are going to be pressed into
allowing more libraries down the line, as people find more reasons to
want to cross compile. That's potentially a lot of additional space
to be consumed in the main repository we ask mirrors to carry. I'm
not sure any of the mingw rebuilt items should be in the main
repository. I'm not saying they shouldn't be allowed to exist..but I
am saying that its probably best to distribute them as their own
collection outside of the main repository

-jef

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

Jeff Spaleta wrote:

On Thu, Jul 10, 2008 at 4:26 PM, Karsten 'quaid' Wade <kwade@redhat.com> wrote:

I am only pointing out the precedents and differences in this case, I've
no idea yet if we are in danger of slipping down a slope.


I haven't seen anyone put forward any rationale by which to limit
which libraries we distribute compiled against mingw. The libraries
so far suggested are specifically targeted so libvirt can be more
easily developed. But there's no bright line painted as to why we
should not allow all libraries to be rebuild and packaged if people
desire them. If we let the relatively narrow set of libraries be
rebuilt for the virtualization development needs as part of our
repository, then we are opening the door for all libraries to be
rebuild and packaged. I haven't seen a credible argument to limit
mingw rebuilds to just what libvirt needs. And quite frankly we
shouldn't be setting limits on intended use. If we allow any mingw
built libraries into a repository we control.. then we should let all
libraries be rebuilt with mingw.


+1

Here's why:

I want Fedora to be a premier platform for developing software. I want
Fedora to attract developers of software to it. Having mingw and a
non-excluded range of OSS libraries furthers this goal by allowing
developers who might have had to develop on a proprietary OS or with
proprietary libraries to now build on Fedora with OSS libraries instead.
If these developers come to enjoy using Fedora, they will see more
reason to enhance their experience on Fedora leading to more
*contributors* to OSS software.



We should not get into the business
of trying to determine if one sort of development need for a library
is more worthwhile than any other. So if we let in what libvirt needs
rebuilt in mingw, I'm pretty sure we are going to be pressed into
allowing more libraries down the line, as people find more reasons to
want to cross compile. That's potentially a lot of additional space
to be consumed in the main repository we ask mirrors to carry. I'm
not sure any of the mingw rebuilt items should be in the main
repository. I'm not saying they shouldn't be allowed to exist..but I
am saying that its probably best to distribute them as their own
collection outside of the main repository


So here's a question:

We've already established that mingw doesn't fit the model of secondary
arches but does it fit the model of EPEL and OLPC? Can we have a
repo/sub project that has its own branches of packages in CVS and builds
that target windows using mingw on Fedora? Is that something we have
enough interested parties to do?


Note: This may or may not scale very well when we think of expanding it
to the realm of all cross-compilers. But we probably aren't talking
about potentially rebuilding every library in Fedora for the Lego
MindStorm :-)


-Toshio

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

On Fri, Jul 11, 2008 at 9:47 AM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> We've already established that mingw doesn't fit the model of secondary
> arches but does it fit the model of EPEL and OLPC?

Have we? I'm not sure we have enough people talking about it yet.. to
be sure. I have questions, I'm deliberately playing the ignorant fool
(when in doubt go with what you know) hoping someone with intimate
knowledge on where the 2ndary arch infrastructure chimes in on whether
or not we can setup a mingw built tree 'like' a 2ndary arch.

> Can we have a repo/sub
> project that has its own branches of packages in CVS and builds that target
> windows using mingw on Fedora? Is that something we have enough interested
> parties to do?

Can we? We'd need to think hard about how we want to integrate any
mingw spec logic into existing specfiles for libraries. Or do we let
the mingw specfiles run completely parallel to our existing packages
and not try to work mingw logic into our existing specs? I think the
cross-compiler aspects of mingw bring some unique packaging challenges
on us, that far surpasses the sort of problems we've seen with trying
to support EPEL as branches in our existing cvs for example. Looking
at the -devel-list thread concerning dep resolution work arounds tells
me doing this right isn't going to following an easy-bake-oven recipe.

For example, is it going to matter as to what branch of Fedora mingw
built DLL's are actually built on? Or can we lump DLL packages
together into a single repository regardless of which version of
Fedora they were actually built inside of? If we setup a mingw built
repository would it need to have release branches that matched the
Fedora release branches? Or can we get away with a mingw repository
with its own release branching schedule that was not tied directly to
the Fedora release schedule? Since none of the resulting DLL payloads
can be used natively on Fedora... can you essentially 'use' such a
standalone mingw repository equally well across different Fedora
versions to install DLL packages?

Certainly right now there is a a small..core..group of developers who
are pushing mingw compiled libraries forward specifically for libvirt
client needs. Can we set aside some initial project infrastructure
space of a specified size for an initial mingw branch and master
repository..with the understanding that as it grows in popularity
people working inside that branch will need to bring additional
infrastructure to the table..such as mirrors and potentially master
hosting space as the size of the binary pool grows significantly?
I've no problem expending project resources as a genesis for a mingw
built repository of packages, but I'm not sure we can make a
commitment to host a fully realized mingw built library space given
pressure to host other contributed materials.
In that sense its a lot like 2ndary arches. If the mingw branch is
going to be successful, we are going to need its contributor and
userbase to bring some infrastructure to the table for it.

> Note: This may or may not scale very well when we think of expanding it to
> the realm of all cross-compilers. But we probably aren't talking about
> potentially rebuilding every library in Fedora for the Lego MindStorm :-)

This won't be the last cross-compiler of import that we are going to
have to deal with. And I'd rather craft a general framework for this
sort of thing now, that we are comfortable with using as a starting
point in the general case when we have another cross-compiler
sub-community wanting to do work within the Fedora project umbrella.

-jef

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

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.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

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

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.

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

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.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 59 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

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

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?
--
Axel.Thimm at ATrpms.net

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

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?
--
Axel.Thimm at ATrpms.net

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

On Fri, Jul 11, 2008 at 10:47:34AM -0700, Toshio Kuratomi wrote:
> We've already established that mingw doesn't fit the model of secondary
> arches [...]

Depends on what we define with secondary arches. I thought the
definition is

a) if some rawhide/update build fails on these it doesn't matter, the
package get's pushed for the primary archs.
b) secondary archs have a different mirroring space

But other than that secondary archs meant to my understanding a Fedora
sharing the same src.rpms (to the biggest extent possible, e.g. grub,
where grub actually can work etc) on that particular arch including
kernel/glibc, or not?
--
Axel.Thimm at ATrpms.net

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