[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Handling of GnuWin32 source packages


Volker Grabsch wrote:

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

Indeed, but your proposal does not solve that.

What would be a real solution is to treat Win32 as a separate architecture, for which packages are always cross-compiled (at least in the beginning). People wishing to use the packages would use dpkg-cross to generate packages they can install on their development systems, and the packages would only be listed in the package list for the win32 arch, so no overhead for the ordinary user.

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.

Indeed, and this would only be a stopgap solution, but it's better than duplicating source packages.

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

Indeed. I think in the long run a separate architecture would be preferable.

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.

True; however especially the libraries you are talking about (libz, libpng, ...) had security issues in the past which required a bugfix release. Having to apply the fix to two different versions doubles the work of the security team.

In the long run, a lot of free software projects strive for their own obsolescence. If a porting patch is accepted by the upstream developers, and there are a few test cases in place to catch regressions, all that remains to be done is to protect the project from optimizations from excited Gentoo people. :-)

   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.

On Windows, you already are in DLL hell, so shipping all DLLs you need and installing them in your program directory is a wise thing to do.

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.

True. The long term solution -- new architecture -- does that.

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

I figured we could just assimilate them. :-)

   Why should I ask 10 or 20 busy Debian maintainer to duplicate
   work that is already done by the GnuWin32 project?

Because it is, in the long run, duplication of work already, and both projects could benefit from synergy (I feel dirty for saying that word now) effects.

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.

Indeed, and nothing stops you from supplying those, as they are not in Debian already.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: