[Pythonmac-SIG] fink vs DarwinPorts?

[Michael Twomey]

On Sat, 5 Feb 2005 13:46:49 -0500, Bob Ippolito <bob at redivi.com> wrote:
> 
> 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.
> 

Fair enough, I like using binary packages for this, as well as rolling
back to older versions.

> Writing darwinports packages is easy too, so that's not a real point of
> difference.
> 

Agreed, I've looked at the darwinports portinfo files and they look
pretty simple.

> > 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).
> 

Ok, this is definitely the main source of our disagreement, I love apt
and debian, whenever I've needed it debian has been there for me and
worked perfectly, it's saved my behind so many times I've lost count.
So when choosing a system on the mac I am instantly biased towards an
apt based solution.

> 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.
> 

As a rule I dislike flavours (though fink does give you ssl vs
non-ssl, and x11 vs non x11 packages), the combinational explosion of
options you get means it gets very hard to debug issues with one
machine vs another (this probably is another hint of my bias, my
arguments stem from maintaining multiple machines, for my laptop this
is all really moot :) ).

> If I don't want the entire world to be downloaded and installed when
> installing a simple utility or library.
> 

This isn't really the fault of the system, more of the packager. Fink
can handle useful deps just fine, it's a question of whether the
packager uses them properly. It's pretty much the same on all systems,
AFAIK. As a point of reference, building the suse python package is
painful as it draws in a huge amount of deps so it can build all the
variant packages.

Besides, I thought the reason most people use a packaging system is to
pull in a given app's required world of libs rather than download and
compile each one?

> 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.
> 

I wouldn't use fink to distribute apps, or for that matter any of the
packaging systems. In the case of OS X I would link against Apple's
libraries, and bundle others I needed.  By bundle others, I mean I
would build them myself, ensuring they linked against Apple's stuff.

As far as I know, none of the packaging systems touch Apple's
libraries (any that went near /usr would be bad news, I'm looking in
the direction of the initial release of portage here), they just link
against their own versions. With ABI being what it is these days this
is a prudent choice. Entire systems like openpkg make this their
entire point, they statically link against their own libs so you are
isolated from the core OS, a critical point when deploying against
multiple OSs.

> Darwinports does have its fair share of disadvantages too, but it's
> certainly a heck of a lot less annoying for what I do.
> 

Personal preference here, I think it's just a question of which system
you like, and which system rubbed you the wrong way when you tried it
(for me it was darwinports).

> 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).
> 

I completely agree here. I've adopted a multi-prong approach which
works well for me:

1. Use Apple's python (and your sweet pyobjc) for mac apps
2. Use a packaging system (fink, darwinports, whatever) for an X11 or
non-gui python. This is what I use from command line. Generally I need
more deps for some of this stuff, so a packaging system helps a lot
here.
3. 'python setup.py install --prefix=$HOME/unix' and add
$HOME/unix/lib/python2.3 to my PYTHONPATH for other stuff which isn't
packaged by anyone, generally pure python stuff.

This way I keep the mucking about with my system as root to a minimum,
and get reasonable value from pre-packaged stuff.

Packaging systems should be the job of the OS vendor in this day an
age. To be honest, I find it shocking that Apple's packaging system
doesn't have a package remove, it would make it far more viable. Even
better if they adopted a real packaging system like apt ;)

mick