Stephan Hermann sh at
Sun Nov 27 12:14:43 CST 2005

On Sunday 27 November 2005 17:54, Mike Hearn wrote:
> On Sun, 27 Nov 2005 16:55:50 +0100, Stephan Hermann wrote:
> > Yes, and who should support those bundles?
> Er, presumably the people who wrote them, ie upstream - they're the ones
> who understand how the software works, not you. Besides, what
> exactly does "support" mean here: distributions should be able to patch
> software as they see fit likely causing unpredictable side effects?

Ok, thinking about that, the e.g. Mozilla devs are providing you with a 
complete different binary then the original Mozilla? (I'll take mozilla as an 
example, because it's OSS and can be compiled either on unix/linux and/or 
Well, thinking of that I actually have no clue about compilers, upstream 
sources or something like this, I could possibly better in reading 
documentation, e.g. .

"Compiler & Linker

The standard compiler for Mozilla on Windows is Microsoft Visual C++, version 
6 or later. It is also possible to compile Mozilla using the mingw gcc 
compiler: see Compiling Mozilla With Mingw."

Wow...I need at least for the supported environment one commercial compiler 
tool chain from MS. Well, yes there is the possibilty of using mingw gcc 
(which runs nicely on windows btw) but this is not official (see way to build the windows binary of 
mozilla. Nevertheless I think it will be hard to maintain a crosscompiler 
toolchain, when the distributors main gnu gcc toolchain maintainers are 
concentrated to get gcc/g++ clean for shipping.

Actually, I don't really have a clue, forgetting my experience.

> > So, stating this, how is a distributor able to rebuild windows sources
> out of
> > a linux compiler toolchain? How is a distributor able to rebuild a
> > windows source inside a running wine, when there is no opensource MS
> > VC/C++ compiler?
> You don't have to use VC++ to build Windows binaries, that's a bizarre
> idea. You can use cross-compilers to do it on Linux just as well.
> I've built Win32 PE binaries on Linux before, it's actually quite easy.
> Now whether the Mozilla build system specifically can cope with that, I
> don't know. But that's an unrelated problem.

Yes, I never said you can not...but you introduce another "will be buggy" 
package into the distribution. Think, we are writing here about two different 
views. One view is upstreams view, and yes, they can do whatever they want, 
at last it should be not against the law :)
The second view is the distributor and packagers view. The packager has to 
provide support for his package, even when upstream doesn't exist anymore, 
but a lot of users are using this software. The distributor has to make sure, 
that those packages are supportable, because they're depending on the 
packagers. So, tell me, someone who never worked with Windows, who doesn't 
have windows at all, how can he support this? Don't think in upstream ways.

> In the future I can see most of Wine being built that way (as real PE DLLs
> instead of the current ELFDLL hybrids). A few programs expect to be able
> to do things like parse the DLL headers straight off disk, load DLLs into
> memory themselves bypassing the dynamic linker etc, and one way to support
> that is to use real PE DLLs with a cross-compiler toolchain. The .so files
> Wine uses are already not true ELF files, they just look like it.
> Switching the actual file format used would not be such a big deal.

For sure, this will be the future, as long the software vendors don't sell 
software for Linux. For me is wine only a possibilty to run windows software 
as long there is no alternative for Linux/Unix. When there is an alternative, 
I'll (or even others) are using the Linux/Unix alternative, not the windows 
software. And if this software, where I don't have an alternative, is not 
running in wine, well...I will forget to use this windows program. 

> > Yes. Speaking of OSS, it's in the packagers responsibility to decide what
> > to build and what to provide in a package and what not.
> I strongly disagree with this idea, it introduces middle-men into the
> system for no good reason. It's also one reason why I support upstream
> providing binaries directly through systems like autopackage, bypassing
> distributions (apart from it being more efficient generally). The people
> who created the software are the ones who know best how the user should
> experience it - indeed it's *their* right to decide that, seeing as how
> they put the work in to create it.

Well, then you should change your license and/or kick the users to use 
something else then the supported distribution package manager. Well, 
thinking about that, I can't encourage anyone to use those software, which 
has no alternative then to break the distributors package management.

> Put another way, I've wasted far, far too many hours of my life debugging
> problems in Wine introduced by distributors and 3rd party packagers who
> arbitrarily overrode upstream decisions they knew nothing about.

That's why the packager is responsible for the software he packages. If 
upstream would tell bugreporters to ask their distributors first, you 
wouldn't have any problems. The same applies to the packager. If he finds out 
that upstream source has a bug, then he can come to upstream and file a bug. 
Everyone is happy and it works. 
And this is one point, why packagers have actually some clues about their 
packages they packaged and supported.

But not me, I'm totally clueless...


More information about the ubuntu-devel mailing list