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

On 11/28/05, Mike Hearn <mike at plan99.net> wrote:
> On Sun, 27 Nov 2005 19:14:43 +0100, Stephan Hermann wrote:
> > Ok, thinking about that, the e.g. Mozilla devs are providing you with a
> > complete different binary then the original Mozilla?
> Well yes. This already happens - you can't patch Firefox and still call it
> Firefox. Their trademark policy doesn't allow that.
We already do this. The diff to mozilla-firefox is about 15k big,
compared to the 'firefox' package we have in breezy.

> It was suggested that Wine may be shipping pre-compiled executables in
> future: in fact we already do this in a way, as Wine will try and download
> the Mozilla ActiveX installer the first time it's needed, so it makes no
> difference whether it's included in the package or not. Including it
> would be convenient for the user because it means they won't be disturbed
> by a download popping up at some point (and a few programs don't expect
> loading a widget to trigger downloads), but the bits on the hard disk are
> the same at the end. So it makes no sense for you to say "we will not
> include this" because the source code will already fetch it if it's
> missing.

Well, the download approach does not inflict redistribution problems
for distributors. So please keep the current solution.

> > 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,
>
> That's not true. This whole idea of packagers being separate from
> "upstream" is bogus

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

No. You are seriously wrong at this point.

> > Well, then you should change your license and/or kick the users to use
> > something else then the supported distribution package manager.
>
> Actually for a long time the stock answer to Wine tech support queries is
> "did you try building from source yourself", and I'd say this clears up
> about 50% of problems. Usually because the distro has provided wrong
> packages, or out of date packages, or both. So in a way we already do the
> latter.

Then how about working with the packagers of the distribution in
making the packages better? Please rethink about your attitude towards
packages which try to provide useful packages for the users.

> > 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.
>
> Your solution to "packagers introduce bugs" is "bugs should be
> reported to the packager first"? What a strange idea - why not just
> eliminate this middle layer entirely and have packaging be an upstream
> community effort like documentation or artwork. This way we don't have to
> deal with people who think it's funny to compile out logging code, or wrap
> programs in strange scripts that break upgrades, or who "fix" non-existent
> security holes.

I think it is unreasonable overhead for a project like wine to try to
provide good integrating packages for all existant distributions. If
you have problems with the packages distributions provide, please
provide your package maintainers.

> More, for programs like Wine that are completely standalone I do
> not see what value this system of packagers provides. It only adds work,
> and thanks to things like freedesktop.org standards the software can be
> installed from source in the exactly the same way everywhere and it works
> just as well (or better).

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.

--
regards,
    Reinhard