Re: Handling of GnuWin32 source packages
On Mon, Mar 13, 2006 at 08:28:24PM +0100, Simon Richter wrote:
> Volker Grabsch wrote:
> >I'm trying to build Debian cross compiled packages of win32 libraries.
> >As upstream sources I use the (already patched) sources from the
> >GnuWin32 project. (http://gnuwin32.sourceforge.net/)
> IMO what would make more sense is to try to get the patches integrated
> into the "regular" libpng package, so that it can build a cross
> development package as well (like wxwidgets can, for example). That
> would make it incredibly easier for the security team to handle this as
> only one source package needs to be updated.
It makes more sense to port their distribution to Debian.
(well, only parts of it ... just the library packages, of course)
However, your idea was my first thought. But it is naive, and leads
to bigger problems. Please take a look into the other threads about
gnuwin32. Here's a short summary:
1) Debian isn't intended to produce cross compile libraries and/or
compilers. Even as separate packages there is a good chance the
majority of Debian developers don't want them beeing included
2) Convincing each Debian maintainer of these libs to include an
extra binary target will be very hard, and the project as a whole
may fail if only one of them doesn't like it.
3) It's much work for a Debian maintainer to keep track with the
mingw32 builds. Some packages are prepared to produce lots of
binaries compiled with different ./configure options. But most
of them aren't, so it'll compilicate their debian/rules.
Also, all these libs would need a build-dependency on the
4) Versions: It's much better when the packages use the same version
the GnuWin32 project uses. For instance, a Windows user will be
able to get the DLLs (and other runtime stuff) from there, and
is able to run my cross compiled EXE.
However, if there are differences between GnuWin32 and the Debian
cross compiled packages, one may have to ship own DLL files of
that library along with the program which is not desirable.
5) Remember: You want to cross compile. So the Debian cross compiling
should stay as close as possible to the packages one would normally
use with MinGW under Windows.
6) It add in general more work to more persons, than to simply use
the GnuWin32 source packages as "upstream source". The GnuWin32
people *are* already a kind of "distribution" ... compared to
Debian they are organized quite simple, but they already *do*
have some kind of "package formats" and "package maintainers".
Why should I ask 10 or 20 busy Debian maintainer to duplicate
work that is already done by the GnuWin32 project?
Maybe one should try to look at it from another perspective: When
trying to figure out where something belongs to, it's a good idea
to ask: What should happen if something changes?
For example, if I like to port a library to MinGW, should I do this
by providing a cross-compiled binary package of its Debian sources?
Obviously not! If I port something, I want to make it available to
a potentially big audience, which are the Windows/MinGW users, not
the small number of Debian users who want to cross compile.
That's why I'll make my libsmpeg MinGW binaries available to the
GnuWin32 *first*. Putting them into Debian is great, but it's
the *second* step.
I believe that any win32 ports of libraries should go into GnuWin32.
I just want to adapt their packages to Debian.
> If the patches are so intrusive that they break "regular" builds then
> they are not fit for production use IMO.
This is really the minor problem. But even if there were such
patches, what about packages that compile *only* in MinGW? What's
about packages which use the win32 API and never *intended* to
be portable? Such libraries may be interesting, too.
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.