Licensing and technical issues with a Wine package that includes the Mozilla ActiveX Control

On Mon, 28 Nov 2005 20:02:54 +0100, Reinhard Tartler wrote:
> We already do this. The diff to mozilla-firefox is about 15k big,
> compared to the 'firefox' package we have in breezy.

Oh well, I doubt anybody will mind, but according to the trademark policy:

  http://www.mozilla.org/foundation/trademarks/policy.html

you aren't supposed to brand this as Firefox. I guess it really
depends on the nature of the changes and how you interpret that policy but
15k of patch is a pretty huge deviation from upstream.

Incidentally, I've seen quite a few people report that the official
mozilla.org binaries of Firefox are much faster than the Ubuntu versions.
Maybe the reason is buried somewhere in that patch?
 
> Well, the download approach does not inflict redistribution problems for
> distributors. So please keep the current solution.

You're saying it's OK for a program to go automatically download something
once it's been installed but it's not OK for that download to be included
in the package. They seem equivalent to me, even with the VC++ runtime.

> sure, then why building a distribution at all, if users are able to
> build everything from source?

I think for some things it makes sense. A desktop like GNOME needs to be
integrated with the kernel and so having a central point where these core
operating system pieces are tied together is good. But when this is
extended to *everything* it's not really a good thing, because random 3rd
party applications don't need it and it just adds overhead and
complications.

> Then how about working with the packagers of the distribution in making
> the packages better? 

Well, we did. The guy who did the Red Hat packages went and rewrote the
Gentoo ebuilds for instance. But look at Wine in Debian - lots of bugs
have been filed, nothing ever changes. And the Gentoo ebuild was fine for
a while, now it started going downhill again. Meanwhile every time one
problem is fixed, 3 more new packages crop up with new problems. Why
bother spending all my time on this when I can just say "install from
source" and know it works fine? 

> wine is not completely standalone. If it was that easy as you try to
> suggest, you wouldn't complain about bad packages, would you? I mean,
> out of date packages are not the only problem you mentioned.

Well, it requires tracking the dependencies of the application as they
change from version to version, which as they're optional often doesn't
happen. People assume that configure will bail out if a new dependency is
added so they don't have to follow development (wrong), or that
dependencies will never change (wrong).

Beyond that it's easy. The problem is when people are tempted to "improve"
things. For instance,  "hmm, regedit doesn't look
very useful, I will split it up into an optional wine-utils package like a
good packager" not realising that programs rely on it being there. So when
a program crashes 10 frames deep on startup because it's missing a
registry entry the installer should have created, but didn't because
regedit was missing, you can easily spend 2-3 hours figuring out what went
wrong. And when you find out it's not really a bug at all but an
"improvement" - well it makes you angry. Your time was wasted by the
system.

Anyway. We've gone way off topic here. My original question was what's
wrong with shipping PE EXE/DLL binaries in a Wine package, which was
answered, and now we're on the topic of whether distributions should
randomly change upstream decisions like what to ship. I don't see it going
anywhere ...