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