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: fink-de...@lists.sf.net). 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
------------------------------------------------------------------------------ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
