[Pythonmac-SIG] fink vs DarwinPorts?

[Bob Ippolito]

On Feb 6, 2005, at 5:55 AM, Michael Twomey wrote:

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

So then pretend you're using fink and install the same flavor (probably 
the flavor that depends on a third of the open source software ever 
written) on every machine.

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

More linux pain :)

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

Yes, but the "world of required libs" is usually mostly satisfied by 
what is already on the system, though Fink doesn't care because it 
would rather download and install its own version of everything.

>> 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 will use Apple's libraries whenever suitable.

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

I've been burned by apt on multiple platforms, so :)

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

Since you use two different Pythons, how on earth can you use 
PYTHONPATH?  I use pth files sitting in directories that are picked up 
by a particular Python.

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

Well, even if apt didn't suck, its license does.  Apple stays away from 
GPL software.  I'm pretty sure that there is exactly zero GPL code in 
Mac OS X (not Server) until you install Developer Tools.

-bob