>> 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: fink-devel@...).
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.