On 26.06.2009, at 16:51, Dmitry Timoshkov wrote:
"Emmanuel Maillard" mahanuu@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 ;)