(Damn gmail, why can't it reply to lists by default, this really steals my thunder)
---------- Forwarded message ---------- From: Michael Twomey <[EMAIL PROTECTED]> Date: Mon, 7 Feb 2005 01:19:46 +0000 Subject: Re: [Pythonmac-SIG] fink vs DarwinPorts? To: Bob Ippolito <[EMAIL PROTECTED]> On Sun, 6 Feb 2005 09:49:15 -0500, Bob Ippolito <[EMAIL PROTECTED]> 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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
