On Feb 5, 2005, at 10:18 AM, Michael Twomey wrote:
On Sat, 5 Feb 2005 09:21:15 -0500, Bob Ippolito <[EMAIL PROTECTED]> wrote:
Another reason is that it is based on the debian apt packaging system,
so you have a very controlled build environment. Their .info package
descriptions are succint and it is easy to roll your own packages.
Controlled?! By who? Certainly not the user.
When I say controlled I am coming from a linux packaging point of view. The builds are performed inside /sw/src and packages are assembled from there. Unless you have an utterly insane program whose source insists on dropping files all over the system during a build this makes it easy to control what goes into the package. Besides, writing .info files is fairly easy compared to deb info stuff or rpm build descriptions, only gentoo gives a nicer build description format.
darwinports uses an image based system where each individual package is installed to its own place. When a particular port is activated, hard links are made to where they need to go so the rest of the system will see it. deactivating a port simply removes these links.
Writing darwinports packages is easy too, so that's not a real point of difference.
This is all a point of view, I like fink, it packages what I want neatly, it doesn't get in my way and I don't spend all my time re-compiling packages due to arbitrary changes (unlike gentoo, this strip pretty much summed up my experience, http://comic.escomposlinux.org/ecol-161-e.png). The fact that fink applies altivec patches to python numarray is another part of it which endears itself to me.
My problem with fink is basically their choice to use apt. As a point of reference, I really don't like Debian either (though it is better than most of the other Linux distributions in my experience, but that doesn't say a whole lot).
Darwinports gives me the control I need with its flavors (essentially letting you build the package with custom flags, such as with or without X11 support for Vim). I can build several of these and activate/deactivate them whenever I want.
If I don't want the entire world to be downloaded and installed when installing a simple utility or library.
Fink really gets in the way of my efforts to develop redistributable software in that it's dependency resolution is very naive and effectively installs its own OS (minus kernel and a very very small subset of the libraries that OS X ships with). I don't want to distribute an OS with my applications, just the one or two libraries that are actually needed beyond what is included with the OS. I am fine with letting Apple upgrade zlib at their own schedule. I have no need to distribute applications with the absolute latest version of zlib, OpenSSL (and everything else) because I trust Apple (way more so than Fink) to upgrade the OS's version of zlib if there is an actual problem.
Darwinports does have its fair share of disadvantages too, but it's certainly a heck of a lot less annoying for what I do.
All that said, I don't trust either darwinports or fink do manage Python software. I will use darwinports to build the dependencies for some things, and build the Python packages myself. As far as Mac specific patches to Python software goes, I was the originator of them in many cases... so these "conveniences" don't really apply to me because I am building and hacking on these things myself anyway (and in these cases, both fink and darwinports would get in my way, which is another reason I don't use them for Python software).
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
