-----Original Message----- >From: Dmitry Timoshkov <dmi...@codeweavers.com> >Sent: Dec 21, 2008 10:45 PM >To: Dan Kegel <d...@kegel.com>, Roderick Colenbrander <thunderbir...@gmx.net> >Cc: wine-devel@winehq.org, z...@drayer.name, ies4...@kronenberg.org >Subject: Re: Linking to a Mac OS X build of Wine from winehq.org/download ? > >"Dan Kegel" <d...@kegel.com> wrote: > >> On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander >> <thunderbir...@gmx.net> wrote: >>>> Say, http://www.kronenberg.org/darwine/ seems to be a popular source >>>> of nearly up to date wine builds for the mac. How about we link to it >>>> from http://winehq.org/download/ ? >>>> >>>> Furthermore, are his packages good enough to support? >>>> If so, how 'bout we ask him to add links to bugzilla and >>>> the appdb from his page? >>> >>> Most importantly we need to get rid of the Darwine name. It causes a lot of >>> unneeded confusion. >> >> Yes, I would like to keep Darwine as the name of the old powerpc project >> that combined an x86 emulator and wine. >> >> Can we convince Mike and Zach to switch names to just plain Wine? > >And change the licencing conditions to LGPL, currently that page states >"Darwine and wine are released under the gpl". They also have to remove >any differences between WineHQ sources and their ones, otherwise it can't >be supported via WineHQ. > Dan and Dmitry:
What I would like to see is the changes made by Zach and Mike incorporated back into the main Wine code. Both Mike and Zach have approached building Wine releases in the two structures supported by Apple: Drag and Drop where you grab a pre-built Application object and move it into the Applications folder and the use of the Apple installer with an installable 'package' much like the use of apt or yum. There is great debate as to which is the best approach and, basing this on the struggle within and outside of the OpenOffice.org/NeoOffice.org MacOSX porting projects, I would like to avoid this problem as best we can. Firefox and Thunderbird use the first approach, but many projects use the latter. The Wine project should pick one as the formally supported installation method and allow others to support the second. I don't have a favorite, as deinstallation of the program is easy and involves an additional step when using the second installation method. Again, restating my first sentence in the last paragraph is that we need to bring back into the Main Wine codebase those changes needed to successfully complete a build on the Intel MacOSX system. Darwine should remain a project for incorporating the x86 emulator, Qemu and Wine. This should reduce MacOSX user confusion and get all of the pieces together. Further work may be required to fully support all functionality of the Wine project, such as font support, as time progresses. James McKenzie
