Re: [Fink-devel] fink wine package, Tiger and Wine?

[Damian D. <da...@ta...>]

Hey Joerg,
>> HTH, let me know if you hit any issues with the packages.
>>     
> So far I've installed neither Fink nor MacPorts, as I thought the first was outdated and the second seems to do everything, even compilation as root, which I find unacceptable. I merely looked at both online package descriptions.
>   
IIrc compilation is done in a fakeroot environment on Fink (don't quote 
me - you'd best ask on fink-devel for that: fin...@li...).  
Fink compiles/creates a deb file which you can then install. This means 
you don't have to install the dev packages, and/or can remove them.
> As far as Wine is concerned, I wanted to see how far I could go with Apple only tools. On Leopard, only the XCode install DVD I got with the machine and XQuartz are needed to build a working Wine. (I also submitted some patches).
>   
That sounds about right, although up until recently this was not the case.
> However, I'm in need of a package management system, as e.g. I haven't even installed git on the Mac.
>   
This is why I use fink :).  Self-compilation becomes tedious very 
quickly.  Fink permits you to create new packages or maintain existing 
ones quite easily.  For updated wine versions, I usually just update the 
version number in a packages config file, and run fink install wine.
> What I see from the package description of both systems is that the build dependencies look really huge. I got the impression that Fink and MacPorts build a second system from OSS only in parallel to Apple's libraries.
>   
The deps are quite big, but, for most things there are virtual packages 
that can satisfy the dependencies using xcode/etc.  Fink does require 
xcode and uses xcodes's gcc, although you can also install your own.  
Similarly X has virtual packages and so do many other tools and 
libraries.  The core isn't too big, mostly its dpkg, tar and some other 
gnu libraries that aren't compatible with apples.
> Well, I should probably write this stuff to an appropriate Fink mailing list rather than private e-mail. Feel free to forward or add CC.
>   
CC'ed to the list.
> A) large Wine dependencies
> I know that wine's configure complains about lack of dbus & hal, but do these libraries make sense on a MacOS system?  I believe MacOS has its own notification system.  So from the little I know, there's no value to depend on and include these libraries.
>
> arts, esound, jack ... I know it's nice to have a fully populated winecfg audio tab, but is that really useful? On the MacOS, I go with CoreAudio and that's all (I'm no music expert).
>
> Perhaps the lack of binary distributions makes this matter worse. On Ubuntu or Suse, a run-time dependency on foo-dev means a download of 100KB.  On Fink and MacPorts, it means producing the -dev package, which means download and compile of the complete source and their dependencies. For mesa/Xorg, that makes quite a difference!
>
> For comparison, I got a working Wine (without lcms and a few others) on Leopard with nothing but Xcode and XQuartz, whereas Fink and MacPorts make it look like a job of several hundred megabyte of downloads, compilation and disk space usage.
>   
It may make sense to get rid of these  dependencies on osx, however that 
would mean that if someone wanted to use arts/esound etc they would have 
to build stuff themselves.  As far as I can see most package management 
systems have to make some sort of compromise on functionality/dependencies.
> B) Duplicating programs and libraries available from Apple via Xcode
> Reading just the online package descriptions, I could not see how many 'meta' or 'virtual' packages there are for the SW that may come from Apple, e.g. gcc-4.0, gcc-4.2, make, autoconf, flex, Xorg/XQuartz, openssl ...
> I would try to avoid duplicating all that. A collection of pseudo-package seems a nice way to solve this. It would be the user's choice to "install" them.
> OTOH, I can understand that packagers prefer to rely on the up to date online OSS packages, because e.g. Apple's autoconf may be as old a Tiger 10.4.0 on the user's machine, while it's 2009 now.  IIRC the Fink or MacPorts FAQ mentions this reason.
>   
Fink gives you this option for many packages - allowing you to chose 
between a virtual package and the real one.
> 17 years ago on SunOS, I myself built a parallel hierarchy of OSS programs in a directory distinct from /bin/ and /usr/bin, with some annoyances (e.g. known incompatibilities between Sun tar and GNU tar).
>   
Fink also keeps its own GNU tar :).
> IMHO, the best would be a collection of "fake" packages for Apple/Xcode provided programs, probably with low version numbers, then see how far one can get. ... May cost a lot of time and cause headaches to test and maintain compatibility.
If you're interested in Fink, you'd probably best get in touch with the 
developers and have a chat with them - I don't have enough time to 
maintain more than the odd package now and then unfortunately.
Cheers,
Damian