why is Kronenberg's Wine/Mac work blacklisted on winehq?

Mike Kronenberg mike.kronenberg at kronenberg.org
Fri Jun 26 15:42:50 CDT 2009


On 26.06.2009, at 16:51, Dmitry Timoshkov wrote:

> "Emmanuel Maillard" <mahanuu at free.fr> wrote:
>
>> Darwine tools WineHelper and create_darwine_distrib script are not  
>> GPL  but LGPL.
>> Don't know for Mike Kronenberg patches or other stuffs, but we  
>> never  change Wine licensing
>> in Darwine.
>
> Darwine site claims that it's under GPL. In any case different name  
> means
> a different product regardless of claims and intentions. Darwine is  
> not
> Wine, plain and simple.
>
> -- 
> Dmitry.

This is very true.

Prolog
The main purpose is here, like with other people, to have a crossdev  
option.
I just share the outcome, i.e. binaries.

OS X
My main concern is to have usable builds. Ie, usable without the need  
of a terminal. People on OS X don't care about how stuff works, it  
just has to work.

Vanilla build
I totally agree that by adding certain patches, the builds can't be  
considered as vanilla.
I'll recheck the necessity of the patches again on Tiger and Leopard  
and they really get less and less.

Added libs
As pointed out, the build ships with some libs not installed by  
default on OS X.
My solution is to hide them inside the app folder, this way they are  
not installed in the users /usr or /opt.
Drag the folder to trash and they are all gone at once. Clean system.  
Next try.

Helper app
The average user on OS X needs the help of a launcher to run it's  
windows bins.
This is why I use to pack the WineHelper from Darwine Project.
The WineHelper is LGPL as stated by Emmanuel Maillard.

Where to?
As pointed out above, I'm probably not going to build 10 versions of  
wine, but I will move closer to source, as functionality permits. If I  
understand Dmitry and a lot of other mails (from way back) correct,  
there is no space to include a helper app or 3rd party libs in the  
package as it would "not be wine".

I am perfectly ok with this, as vanilla wine is for me really a "lib".  
There is no space for multi-platform UI stuff in this lib. The lib has  
to remain clean of clutter. But exactly as the back-end has to be done  
right, UI and front-end needs to be done right. For me, this is at  
least specific to every platforms HIGs. As the user would expect it.
This is why there is no room for obj-c, nibs and the like in wine.  
(same goes fro qt et al.)

I could write a basic app in plain c and a shell-script to create the  
needed app bundle (and document types to be launch by wine) at compile- 
time.
The question is, is it of use?
I say no. Most average user tend for "all in one solutions" like  
"Crossover", "Bordeaux" and other "Tools" from the "3rd Party Tools"  
site... as setting up a working environment still is way beyond their  
knowledge.

So what?
I know that codeweavers are one (if not the) the main force behind the  
wine project and respect all the input. The "endorsement" note behind  
the first download on the downloads page is rather misleading as the  
input is way bigger than the hosting for wine ;)

But as this still is an open project, I would grant other  
"distributions and tools" aka "3rd Party Tools" at least a prominent  
(not like now in text) link on the download page.
Then I'd structure the "3rd Party Tools" page similar to the Downloads  
page, where a users sees at once which product might A) run on his  
system B) serve his particular needs.
There is where I'd put my wine builds if they are not vanilla enough  
for semi-official builds :)

Why?
Sysadmins and maintainers need no wine rpm's, they build it.
Power-users need rpms.
But the big lot of the average user is on the lookout for a solution  
to a problem, which they rather find on the "Tools" page.
I will not put % behind these groups, but I think that group 3  
deserves better access to the things they are looking for.

Lookout
I'm not really into these renaming things atm. Removing the "Dar" they  
would lead to new paths, which break installations on a lot of Macs.
As suggested my focus lies in creating a wine.framework, like the mono  
project has done. It should include all the needed libs (3rd party  
libs as framework, too). I succeeded in turning all the dependencies  
into frameworks already. I'm now stuck with wine building against  
these frameworks.
This way, the wine.framework will be cleanly separated from any "3rd  
Party Tool" and can be accessed the OS X way by them, and name/path  
changes will no longer affect these tools as long wine remains wine.



Mike Kronenberg

Btw. I'm alone. And as I know that my builds do not qualify as  
"official", I do a lot of first level support on my builds and wine  
tools... this mail reflects the user spectrum I've got to do with ;)



More information about the wine-devel mailing list