[Pythonmac-SIG] fink vs DarwinPorts?

[Michael Twomey]

(Damn gmail, why can't it reply to lists by default, this really
steals my thunder)

---------- Forwarded message ----------
From: Michael Twomey <micktwomey at gmail.com>
Date: Mon, 7 Feb 2005 01:19:46 +0000
Subject: Re: [Pythonmac-SIG] fink vs DarwinPorts?
To: Bob Ippolito <bob at redivi.com>


On Sun, 6 Feb 2005 09:49:15 -0500, Bob Ippolito <bob at redivi.com> wrote:
>
> 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.
>

'Fraid I'm not getting you here.

The flavour stuff that drives me nuts is the kind that turns on and
off options without indicating in the package name, e.g. python-x11
and python-nox11 vs plain python + some hidden option. This turns a 2
minute "do you have that package?" to a forensic hunt through the
system. Gentoo is very guilty of this (but I suppose that's the entire
point of gentoo, a complete specific distro). If libraries and apps
were properly orthogonal then variants wouldn't be needed in a lot of
cases.

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

Dunno, depends on distro I suppose. Debian and Ubuntu usually do the
right thing, gentoo can be a wild unpredictable ride depends on what
emerge flags you've set.

I've got bandwidth and disk space, I don't really care if fink pulls
in more deps, I've got more important things to do than agonise over
whether I'm optimally using installed libs or not. It would be nice if
someone had access to a compile farm like debian's so I could just
download packages instead of having to compile them, but that's just
icing on the cake.

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

Hrm, really depends on what you are doing. Apple doesn't bundle a lot
of the libs I use so I need to get at them somehow. The ./configure &&
make && make install dance gets a bit tiring after a while.

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

To be honest, I don't really care. After umpteen dvd projects and fink
I still have wodges of disk space.

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

So there ;)

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

Works for me, I'm still using python 2.3 major version, I haven't
switched overt to 2.4 yet, so it doesn't cause me any problems.
Besides it's something I can control with env variables, which I can
switch at will to point at different combinations of work code and
test libraries. Personal preference here. This is probably influenced
by what I am doing.

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

I'm pretty sure Apple uses cups, which in turn is LPGL/GPL. Not sure
how that's relevant here though :)

I'm not asking Apple to use apt, but extending their package utilities
to encompass some of apt's (or indeed any other packaging system's)
features would be nice. I haven't used OS X server, but I'm wondering
how it can compete in the enterprise market without more basic
packaging features.

Well that's enough "my packaging system is better than yours" for me
for one day, haven't seen any conclusive arguments to say one is
dramatically better than another, so it pretty much boils down to
whether a given packaging system gives you the packages you want. And
that's simplifying the issue a great deal. 'Course more people on this
list have spoke in favour of darwinports, so it wins by head count
here.

cheers,
  mick