On Tue, Mar 14, 2006 at 07:21:56PM +1100, Jamie Jones wrote:
> On Tue, 2006-03-14 at 00:28 +0100, Volker Grabsch wrote:
>
> > The extra work of duplicate security fixes is IMHO very small
> > compared to the additional infrastructural work of keeping lots
> > of Debian packages win32 portable, duplicating maintaining work
> > which is already done by the GnuWin32 project.
>
> Is it really that much more work then what is required keep Debian
> packages portable to both the Hurd and Freebsd kernels ? There already
> is a free implementation of a Win32 kernel at ReactOS
> ( http://www.reactos.org/xhtml/en/index.html ) so it's not a non-free
> kernel anymore (although granted it is not a *NIX style kernel)
That's a completely different way. Of course you are free to restart
the Debian-win32 project, so that zlib, etc. will be build there
as *native* packages. This wouldn't cause any changes to the
Debian sources, except eventually some win32 compatbility patches.
This would also be really cool, but it isn't what I plan to do.
I plan to do cross compiling. This isn't supported by Debian, for
many rational reasons. If one plans to create i386 binary packages,
one should build them on a Debian-i386 platform. If one wants to
create arm packages, one should build them on a Debian-arm system.
Consequently, if one wants to create win32 binaries, one should
use a win32 platform. However, there currently isn't any real
Debian-win32 platform. If such platform arises, my programs will
build there as native packages, so there is no need for me to cross
compile them.
Imagine if the Debian-i386 platform whould have to be able to
cross compile any of its packages to any other Debian platform (arm,
...), it would be full of cross compilers, and full of versions of
each library for each platform. This would be an extreme overload
the the whole distribution, so they decided not to go that way, and
instead to build each binary package on its own native platform.
One doesnt cross compile packages to support Debian-win32 (which one
does, as already said, automatically by providing the sources).
One does so to support the propritary Windows system, to make some
programs available to its users without having to run that system.
As a developer, I like making software available for Windows. In
general, it's not a good idea to cross compile my own program
to any platform it'd like to support. It's up the distributions
to produce proper packages, and they'll be able to compile my
program natively on each of their platforms, with less effort and
less hassle than I would have by trying to cross compile it.
However, Windows doesn't have any of these structures. If there
was something like a well functioning "Windows free software
distribution", I'd ask them to support several cool programs and
libraries. But there isn't any.
The only exception which developed some simple structures comparable
to Linux/BSD distributions is the GnuWin32 project. They provide some
uniform package formats, checking dependencies, etc.
So if I like to see a Windows port of my package, I'd have to find
someone of the GnuWin32 project to catch the sources and to maintain
the win32 builds. This would be the ideal "right way".
The problem with GnuWin32 is, however, that they don't automatically
compile and build packages. Instead, each GnuWin32 maintainer has to
provide both, source and binary files. So as a GnuWin32 maintainer you
have to use Windows.
Also, they lack man power, which is typical for such projects. A similar
project, "mingwrep", died because of that simple fact. The GnuWin32
people are better organized, at least Windows installer and ZIP files
(i.e. the "packages") are build automatically. However, they can't grow
anymore until they get more maintainers. However, there aren't enough
free Windows software developer to support them. (If there were, they
would have grown much bigger) So the only way to get more maintainers
to them is to enable free i386-GNU/Linux developers to support them.
This group is already active by building cross compilers, etc.
However, most developers don't support the Windows platform by
providing packages for GnuWin32. They support it by compiling
and creating Windows installers by themselves. While this is the
status quo, and better than nothing, it's not a desireable goal.
To express my thoughts more clealy, I'll try to summarize.
There are in general three ways of using portable free software
and Windows-only software:
1) using Windows and a GNU or BSD distribution,
switching between them
(key words: Boot loader, VMWare, ...)
2) using a free Windows kernel
(key words: ReactOS, Wine, Debian-win32, ...)
3) using Windows
(key words: MinGW, ...)
Way 1) and 2) require you to install another operating system.
However, since most users are (sadly :-( ) tied to the Windows
operating system, I believe that way 3) is the most simple and
most successful way to go.
To create a free software distribution targeting the win32 platform,
one needs enough maintainers. The maintainers can generally be split
into 3 (overlapping) groups:
1) developers using Windows and MinGW
(native builds)
2) developers using ReactOS
(native builds)
3) developers using another system
(cross compiled builds)
Ideally, the groups 1) and 2) should be large enough to handle their
need. Obviously, they aren't.
This is the one and only reason some of us need cross compilers. The
other Debian packages shouldn't have to bother with that issue, and
Debian packages should not be mangled to cross compile, because they
were never intended to do so.
I hope this cleared some things up. A Debian-win32 distribution
is completely another building site than cross compiling packages.
My packages are planed as an addition to the mingw32-* packages of
Debian, not as an addition to the Debian operating system. They are
a workaround to support the development of a free software distribution
for Windows. (not a free software distribution to replace Windows ...
such distributions exist already: OpenBSD, NetBSD, Debian/Linux, ... ;-))
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
