From: Nicholas Clark Date: 15:57 on 04 Nov 2004 Subject: fink Fucking fink. I run fink selfupdate. Firstly the git gives me CVS conflicts. So I figure out where the troublesome files are, wade in with sudo rm, retry and get past that hurdle. Then this one url -f -L -O http://distfiles.dkx.tn.us.finkmirrors.net/base-files-1.9.3.tar.gz % Total % Received % Xferd Average Speed Time Curr. Dload Upload Total Current Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 curl: (22) The requested file was not found ### execution of curl failed, exit code 22 Downloading the file "base-files-1.9.3.tar.gz" failed. (1) Give up (2) Retry the same mirror (3) Retry another mirror from your country (4) Retry another mirror (5) Retry using next mirror set "Custom Mirror" How do you want to proceed? [3] We go round this a few times, until I reach the conclusion that base-files-1.9.3 is too fucking new, and none of the mirrors have caught up. (Else it's not new, but all the mirrors I tried are stale, in which case if they would be so kinds as curl up and die and thereby get out of my fucking way) So I eventually [1] (Give up) and just try to install postgresql74. What do I get: curl -f -L -O http://distfiles.sbn.in.us.finkmirrors.net/libpqxx-1.5.1.tar.gz % Total % Received % Xferd Average Speed Time Curr. Dload Upload Total Current Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:00 --:--:-- 0 curl: (22) The requested file was not found ### execution of curl failed, exit code 22 Downloading the file "libpqxx-1.5.1.tar.gz" failed. (1) Give up (2) Retry the same mirror (3) Retry another mirror from your country (4) Retry another mirror (5) Retry using original source URL How do you want to proceed? [3] What's wrong with the fucking mirrors? Why don't I just blow OS X away and install Debian instead? At least it has a functional packaging system. Nicholas Clark
From: Jarkko Hietaniemi Date: 17:10 on 04 Nov 2004 Subject: Re: fink > > What's wrong with the fucking mirrors? Why don't I just blow OS X away > and install Debian instead? At least it has a functional packaging system. I just simply blow away Fink. Finks sucks rotten eggs. Through a very thin straw. With big chunks in it. So far I think I have repeated the following cycle three times. There won't be a fourth time. (1) Install Fink to get software X installed. (2) Get X installed. (3) Install a few pieces of software (Y, Z) more. (4) Observer how Fink gets more and more unstable. (5) Try compiling something that hasn't been "finked" and notice that Fink has somehow fucked up the system outside of its tree. Yes, it should be impossible. (6) Realize you can live without X, Y, Z. (7) Uninstall Fink with rm -rf. (8) Reinstall X, Y, Z manually with configure --prefix=/opt or the moral equivalent and notice how Things Just Work. (9) Wonder why you ever though installing Fink was a good idea. The only excuse Fink has is following dependencies. And it doesn't get even them right. I don't know whether its Fink to blame or the packagers to blame. But I really don't have the time or interest to fix it. So fuck it. (The only package management I have ever personally seen "just work" was the BSD ports/packages system. It's like CPAN.pm, it just works. Pull down the source, configure, and compile it. No fucking binary installations. AFAICT Gentoo is similar for Linux.)
From: Chris Winters Date: 17:31 on 04 Nov 2004 Subject: Re: fink > (The only package management I have ever personally seen "just work" > was the BSD ports/packages system. It's like CPAN.pm, it just works. > Pull down the source, configure, and compile it. No fucking binary > installations. AFAICT Gentoo is similar for Linux.) I've been meaning to try Gentoo for Mac OS X: http://www.metadistribution.org/macos/ I haven't had that many problems with fink (probably because I don't use it that often), but I like Linux Gentoo quite a bit. Chris
From: Scott Walters Date: 17:36 on 04 Nov 2004 Subject: Re: fink All package systems suck. 1. They foster a dependency on them by programs installed with them 2. They don't play nice with libraries, headers, or programs not installed with the package system 3. There's no machine intelligence in even the simplest form to cope things being slightly off, such as the source files having been replaced with a copy one patch level greater Re #1: with every package system I've seen *except* CPAN, it won't recognize user-installed copies of programs or libraries but insists on installing its own copy. Also, they re-invent DLL hell in that library systems only tolerate one version of a module being installed at a time. Attempting to install a program that requires a newer minor version of a library requires the old version of the library to be installed which requires all of the software dependent on the old version to be installed - when none of this is necessary except installing the new module! Re #1 and #2: I tried to upgrade a FreeBSD system recently. ports has been made part of the *core* installation mechanism, making it unavoidable. I manually upgraded core libraries on the previous install, so pkgsrc was unable to uninstall the old core libraries while upgrading because it didn't know where they came from, so it barfed, ruining the install entirely and failing to upgrade it. This is idiotic. Re #2: Every now and then, someone needs to customize software - god forbid! Often it's because it won't build out of the box. But customize just one program, and every time you try to install anything, pkgsrc/ports/etc will try to either blow away your copy and likely fail to rebuild it or else fail entirely to recognize it's been installed. Re #2: things like gconf and these -config programs in PATH break the package systems as its no longer possible to keep the ports tree and the /usr/local trees distinct - if any version of any library doesn't exactly match, making the multiple installations tolerant of each other, ports will always find the version you installed and try and fail to use it, or else when building things by hand, it'll find the ports version. After using NetBSD since 0.9 and building software by hand my whole life, I've given up. Modern software doesn't build. It's too unportable - the essence of portability is minimizing dependencies, not integrating them in droves. For the 30 or 40 libraries required by anything, one of them is sure to be completely broken on any platform except Linux. Despite weeks of my life invested and every assurance it works, it's been since Mozilla 1.1 since I've successfully built Mozilla on NetBSD - and for the missing dependencies and broken object hierachies, I think the leaked Windows source code would be more likely to build and run. So I run Linux binary emulation and copy binaries and libs wholesale from Knoppix. It's tragic that this crud won't build apart from some elaborate but constricting package system that never seems to work right. Don't these dorks realize that some day Linux might go out of fashion and people will still want to run this software, just like CPM, DOS, Ultrix, and Solaris all went out of style? -scott On 0, Jarkko Hietaniemi <jhi@xxx.xx> wrote: > > > > What's wrong with the fucking mirrors? Why don't I just blow OS X away > > and install Debian instead? At least it has a functional packaging system. > > I just simply blow away Fink. Finks sucks rotten eggs. Through a very > thin straw. With big chunks in it. > > So far I think I have repeated the following cycle three times. > There won't be a fourth time. > > (1) Install Fink to get software X installed. > (2) Get X installed. > (3) Install a few pieces of software (Y, Z) more. > (4) Observer how Fink gets more and more unstable. > (5) Try compiling something that hasn't been "finked" and notice > that Fink has somehow fucked up the system outside of its tree. > Yes, it should be impossible. > (6) Realize you can live without X, Y, Z. > (7) Uninstall Fink with rm -rf. > (8) Reinstall X, Y, Z manually with configure --prefix=/opt or the moral > equivalent and notice how Things Just Work. > (9) Wonder why you ever though installing Fink was a good idea. > > The only excuse Fink has is following dependencies. And it doesn't > get even them right. I don't know whether its Fink to blame or > the packagers to blame. But I really don't have the time or > interest to fix it. So fuck it. > > (The only package management I have ever personally seen "just work" > was the BSD ports/packages system. It's like CPAN.pm, it just works. > Pull down the source, configure, and compile it. No fucking binary > installations. AFAICT Gentoo is similar for Linux.) > > -- > Jarkko Hietaniemi <jhi@xxx.xx> http://www.iki.fi/jhi/ "There is this special > biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
From: Jarkko Hietaniemi Date: 17:51 on 04 Nov 2004 Subject: Re: fink > Modern software doesn't build. It's too unportable - > the essence of portability is minimizing dependencies, not > integrating them in droves. For the 30 or 40 libraries required > by anything, one of them is sure to be completely broken on > any platform except Linux. Despite weeks of my life invested > and every assurance it works, it's been since Mozilla 1.1 since > I've successfully built Mozilla on NetBSD - and for the missing > dependencies and broken object hierachies, I think the leaked > Windows source code would be more likely to build and run. > So I run Linux binary emulation and copy binaries and libs wholesale > from Knoppix. It's tragic that this crud won't build apart from > some elaborate but constricting package system that never seems > to work right. Don't these dorks realize that some day Linux > might go out of fashion and people will still want to run this software, > just like CPM, DOS, Ultrix, and Solaris all went out of style? Amen, brother. In case you ever want to experience excruciating pain, try installing Slashcode to some system not the brand of RedHat Chris Nandor doesn't have installed in his box. No offense to Chris and other OSDN guys, the code apparently works somewhere, but trying to install it anywhere else is aking trying to <censored> <censored> <censored> while <censored> wearing <censored> <censored> dildo <censored> <censored>.
From: David Champion Date: 17:57 on 04 Nov 2004 Subject: Re: fink * On 2004.11.04, in <418A6C2F.2010106@xxx.xx>, * "Jarkko Hietaniemi" <jhi@xxx.xx> wrote: > > Modern software doesn't build. It's too unportable - > > Amen, brother. If someone founds the Church, I will join. Right now I'm too busy installing and configuring dependencies.
From: Luke A. Kanies Date: 19:43 on 04 Nov 2004 Subject: Re: fink On Thu, 4 Nov 2004, Jarkko Hietaniemi wrote: > Amen, brother. > > In case you ever want to experience excruciating pain, try installing > Slashcode to some system not the brand of RedHat Chris Nandor doesn't > have installed in his box. No offense to Chris and other OSDN guys, > the code apparently works somewhere, but trying to install it anywhere > else is aking trying to <censored> <censored> <censored> while > <censored> wearing <censored> <censored> dildo <censored> <censored>. Hah! I actually got slashcode working on solaris, amazingly, but boy was I surprised to find my hostname changed to '-f'! It assumes GNU hostname, which Solaris most decidedly does not have. I was sure I'd been the victim of some retarded hack, but no, just retarded software.
From: peter (Peter da Silva) Date: 23:20 on 04 Nov 2004 Subject: Re: fink > Hah! I actually got slashcode working on solaris, amazingly, but boy was > I surprised to find my hostname changed to '-f'! Heh, we had our HP-SUX (rant held in reserve) changed to "-s". But... I know why ours got changed, because it was in an rc script, but why would any part of slashcode be running as root? (running things as root when they shouldn't be: another rant for another day)
From: Luke A. Kanies Date: 23:22 on 04 Nov 2004 Subject: Re: fink On Thu, 4 Nov 2004, Peter da Silva wrote: > Heh, we had our HP-SUX (rant held in reserve) changed to "-s". > > But... I know why ours got changed, because it was in an rc script, but > why would any part of slashcode be running as root? Truthfully I can't remember right now, but it was probably something related to installing perl libraries or something. It was one of those "well I can spend 5 hours hacking it to run as a normal user or just bloody run it as root" situations. Always yucky, but never befored changed my hostname to '-f'. > (running things as root when they shouldn't be: another rant for another day) I'm working at a software company now; don't even get me started... (Fortunately I'm more design than implementation, but oh, my eyes.)
From: Chris Nandor Date: 21:15 on 04 Nov 2004 Subject: Re: fink At 19:51 +0200 2004.11.04, Jarkko Hietaniemi wrote: >In case you ever want to experience excruciating pain, try installing >Slashcode to some system not the brand of RedHat Chris Nandor doesn't >have installed in his box. No offense to Chris and other OSDN guys, >the code apparently works somewhere, but trying to install it anywhere >else is aking trying to <censored> <censored> <censored> while ><censored> wearing <censored> <censored> dildo <censored> <censored>. No offense taken. Patches welcome. ;) FWIW, it basically works on Mac OS X (where I do all my Slash development) now, too, though you might have to go through some pain to get Apache/libapreq built properly. But that isn't Slash-specific. Oh, and I am told OSDN is dead. Long live OSTG. Whatever that is.
From: Jarkko Hietaniemi Date: 21:43 on 04 Nov 2004 Subject: Re: fink Chris Nandor wrote: > At 19:51 +0200 2004.11.04, Jarkko Hietaniemi wrote: > >>In case you ever want to experience excruciating pain, try installing >>Slashcode to some system not the brand of RedHat Chris Nandor doesn't >>have installed in his box. No offense to Chris and other OSDN guys, >>the code apparently works somewhere, but trying to install it anywhere >>else is aking trying to <censored> <censored> <censored> while >><censored> wearing <censored> <censored> dildo <censored> <censored>. > > No offense taken. Patches welcome. ;) Back when I tried to install that (actually twice, once into a SuSE box, when I kind of succeeded, and once into a RH box, when I ironically failed), as far as solutions went I was more thinking of, say, Semtex, than patches :-) > FWIW, it basically works on Mac OS X (where I do all my Slash development) > now, too, though you might have to go through some pain to get > Apache/libapreq built properly. But that isn't Slash-specific. No indeedy. > Oh, and I am told OSDN is dead. Long live OSTG. Whatever that is. Open Source Total Geeks?
From: Chris Nandor Date: 21:53 on 04 Nov 2004 Subject: Re: fink At 23:43 +0200 2004.11.04, Jarkko Hietaniemi wrote: >> Oh, and I am told OSDN is dead. Long live OSTG. Whatever that is. > >Open Source Total Geeks? That would be a pretty cool name! Alas, it's "Technology Group."
From: David Champion Date: 17:37 on 04 Nov 2004 Subject: Re: fink * On 2004.11.04, in <418A627A.7040702@xxx.xx>, * "Jarkko Hietaniemi" <jhi@xxx.xx> wrote: > It's like CPAN.pm, it just works. Ha. Ha haha. Haaaaaa hahahahahahahahaa. Heh. Oh, there's a killer. Ports does work, though.
From: Jarkko Hietaniemi Date: 17:44 on 04 Nov 2004 Subject: Re: fink David Champion wrote: > * On 2004.11.04, in <418A627A.7040702@xxx.xx>, > * "Jarkko Hietaniemi" <jhi@xxx.xx> wrote: > >> It's like CPAN.pm, it just works. > > > Ha. Ha haha. Haaaaaa hahahahahahahahaa. Heh. Oh, there's a killer. Hey, I had to amuse the crowd somehow... All things are relative. Once you've configured CPAN.pm, you can install A, and it will install the pure Perl dependencies B, C, and D just fine, from remote repositories. When e.g. something depends on externalities like libraries, or the module doesn't pass its tests because of unportabilities, CPAN.pm can't perform miracles. Contrast that with RPM hell (or, Fink hell), and you'll understand how I dare claim that CPAN.pm "just works". > Ports does work, though. >
From: Paul Orrock Date: 17:49 on 04 Nov 2004 Subject: Re: fink Jarkko Hietaniemi wrote: > David Champion wrote: >>* "Jarkko Hietaniemi" <jhi@xxx.xx> wrote: >> >>> It's like CPAN.pm, it just works. >> >>Ha. Ha haha. Haaaaaa hahahahahahahahaa. Heh. Oh, there's a killer. Agreed > Contrast that with RPM hell (or, Fink hell), and you'll understand > how I dare claim that CPAN.pm "just works". apt-get is the holy grail of package management that I wasted 8 years trying to achieve with CPAN, rpm and others. apt-get from network install to fully configured server with apache, perl, half a ton of perl modules and a large dollop of graphics stuff in 1 hour. Now thats package management. Just my opinion :-) Paul.
From: Jarkko Hietaniemi Date: 17:55 on 04 Nov 2004 Subject: Re: fink > >>Contrast that with RPM hell (or, Fink hell), and you'll understand >>how I dare claim that CPAN.pm "just works". > > > apt-get is the holy grail of package management that I wasted 8 years trying to achieve with CPAN, rpm and others. So I understand, I've used but never installed/maintained Debian. (There are some ports of apt to other Linuxes, but since I in general despise package management, so I never have tried those, either.) > apt-get from network install to fully configured server with apache, perl, half a ton of perl modules and a large dollop of graphics stuff in 1 hour. Now thats package management. > > Just my opinion :-) Does apt do source code package management? I don't think I will ever again want binary package management.
From: Juerd
Date: 18:07 on 04 Nov 2004
Subject: Re: fink
Jarkko Hietaniemi skribis 2004-11-04 19:55 (+0200):
> Does apt do source code package management? I don't think I will
> ever again want binary package management.
The packages are always binary thingies, but you can easily download the
source for a package and then make a new package out of it and then
install that. If you don't want to change/patch anything in between,
it's a matter of:
apt-get -b source $source_package
# untested, because I loves binary packages
But if you really want to *enjoy* Debian, let your fear for binary
packages be history and try again. If everything goes as expected,
binary package management isn't bad at all.
Juerd
From: Jarkko Hietaniemi Date: 18:11 on 04 Nov 2004 Subject: Re: fink Juerd wrote: > Jarkko Hietaniemi skribis 2004-11-04 19:55 (+0200): > >>Does apt do source code package management? I don't think I will >>ever again want binary package management. > > > The packages are always binary thingies, but you can easily download the > source for a package and then make a new package out of it and then > install that. If you don't want to change/patch anything in between, > it's a matter of: > > apt-get -b source $source_package > > # untested, because I loves binary packages > > But if you really want to *enjoy* Debian, let your fear for binary > packages be history and try again. If everything goes as expected, > binary package management isn't bad at all. Then someone needs to do a clean re-port of apt to Mac OS X :-) Fink left me with a nasty aftertaste. > Juerd
From: Juerd Date: 18:03 on 04 Nov 2004 Subject: Re: fink Paul Orrock skribis 2004-11-04 17:49 (+0000): > apt-get from network install to fully configured server with apache, perl, > half a ton of perl modules and a large dollop of graphics stuff in 1 hour. > Now thats package management. Indeed. And to illustrate how flexible and fun to use apt-get is on a Debian box that has already been fully configured (my home workstation): Someone had a problem with Mason. Their mod_perl apache died of segmentation faults. I wanted to see if I could reproduce that on my home box. I did not have Apache installed. Within two minutes (I have a fast connection), I had Apache, mod_perl, Mason and a bunch of Perl modules installed. I pasted some configuration example into my httpd.conf, restarted apache and it just worked the first time I tried. Then, to see if the difference between a DSO mod_perl and a static mod_perl mattered, I removed the apache package and installed the apache-perl package. One minute later I had a working Mason again. Then, I removed all the packages that were installed to have a clean system again. This took less than a minute. So in less than ten minutes, I had installed Apache with mod_perl twice and removed it and the required Perl modules that came along with this testing. And my system was still clean. I loves apt. I hates other package management tools, especially those that compile from source and provide no easy option to get a binary, or make uninstalling to get back the clean system hard. Juerd
From: Luke A. Kanies Date: 19:41 on 04 Nov 2004 Subject: Re: fink On Thu, 4 Nov 2004, Juerd wrote: > I loves apt. I hates other package management tools, especially those > that compile from source and provide no easy option to get a binary, or > make uninstalling to get back the clean system hard. I'm a bit torn here... On the one hand, I agree that binary packages are much better (I hate sitting and watching gentoo turn itself into a semi-functional system, and I hate the 30 minute wait every time I install a set of packages). OTOH, man Debian can suck rocks sometimes, especially if you need to do things outside the ordinary. If you ever find your Debian initrd image builder not finding the right kernel modules to load, man you're in for a world of hurt, unless you already know the system so well it won't hit you. FWIW, it's real darn easy to build binary packages with Gentoo, even of already installed packages (although it scares me a bit), using 'quickpkg'. It's very useful for switching package revisions around without having to recompile from scratch every time. But goddamn, I wish Gentoo had some reasonable, recommended defaults. My whole system built w/out ALSA support, because I didn't add it to the make.conf file early enough, and now I've got a gaim that crashes if I install it with ALSA support, and no sound in my online flash comics, and when gaim isn't crashing I'm only getting message notifications when there's no song playing in XMMS (which took me a long-ass time to figure out -- I'd get notifications between songs). Ugh. Basically, you pick a packaging solution, and it sucks. Luke
From: Juerd Date: 23:33 on 04 Nov 2004 Subject: Re: fink Another illustration. In a mailinglist know to you all, Slash was discussed. It made me curious, and I googled for instructions. I thought it would be hard, but still I wanted to try. At 00:23 I typed "apt-get install slash" and started answering a lot of questions, at 00:28 I finally realised that the automatid installation process had edited the wrong httpd.conf (the one in /etc/apache, while the apache that I was using used /etc/apache-perl), and at 00:30 I had a working Slash site. Or at least a front page that looked nice. I loves package management tools when they Just Work. But I wasted FIVE WHOLE MINUTES figuring out why it didn't work at first. Juerd
From: Luke A. Kanies Date: 23:55 on 04 Nov 2004 Subject: Re: fink On Fri, 5 Nov 2004, Juerd wrote: > I loves package management tools when they Just Work. But I wasted FIVE > WHOLE MINUTES figuring out why it didn't work at first. Well, I can't speak for anyone else, but my first attempt at installing Slash was at least 2 years ago, and possibly up to 3. I doubt there was a dpkg of Slash back then... I'm betting (hoping) that the slash code is significantly different now than it was then.
From: David Champion Date: 17:53 on 04 Nov 2004 Subject: Re: fink * On 2004.11.04, in <418A6A66.8020403@xxx.xx>, * "Jarkko Hietaniemi" <jhi@xxx.xx> wrote: > > All things are relative. Once you've configured CPAN.pm, > you can install A, and it will install the pure Perl dependencies > B, C, and D just fine, from remote repositories. When e.g. something Still laughing.... I won't start in on CPAN's crappy defaults which lead me to wait 10 minutes for Net::FTP to time out before it falls back on the ftp or wget command I already told it about. Or wait, I guess I just started in. > Contrast that with RPM hell (or, Fink hell), and you'll understand > how I dare claim that CPAN.pm "just works". Or indeed with Debian hell itself, though I grant I haven't touched the stuff in years. I'll agree that CPAN is better than all these, except ports. But portage/emerge kicks all their pants.
From: Jarkko Hietaniemi Date: 17:57 on 04 Nov 2004 Subject: Re: fink David Champion wrote: > * On 2004.11.04, in <418A6A66.8020403@xxx.xx>, > * "Jarkko Hietaniemi" <jhi@xxx.xx> wrote: > >>All things are relative. Once you've configured CPAN.pm, >>you can install A, and it will install the pure Perl dependencies >>B, C, and D just fine, from remote repositories. When e.g. something > > > Still laughing.... > > I won't start in on CPAN's crappy defaults which lead me to wait 10 > minutes for Net::FTP to time out before it falls back on the ftp or wget > command I already told it about. Or wait, I guess I just started in. Of course I'm somewhat biased :-) but I suppose you have *done* something about the crappy defaults like submitted bug reports/ code/suggestions to the Perl maintainers. If not, I really can't bring myself to care...
From: David Champion Date: 18:05 on 04 Nov 2004 Subject: Re: fink * On 2004.11.04, in <418A6D99.3030204@xxx.xx>, * "Jarkko Hietaniemi" <jhi@xxx.xx> wrote: > > Of course I'm somewhat biased :-) but I suppose you have *done* > something about the crappy defaults like submitted bug reports/ > code/suggestions to the Perl maintainers. If not, I really > can't bring myself to care... Actually, no (but probably you know that already): for the number of places I actually want to use CPAN.pm it's not worth the time. I don't like to submit bug reports without investigating the bugs and having some information about the problem. And in general I want my software managed as packages, not installed ad hoc as if all my servers were desktops, so I don't use CPAN except in odd one-off circumstances. FWIW, except for this particular problem, I'm not convinced that the problem is necessarily CPAN.pm's. It might just be flaws in the modules' build stages. But CPAN.pm inherits that set of problems, just as much of RPM and fink hell are inherited from their packages. If I had a greater use for it, I'd spend more time on the problem. For now it's faster just to kill the destined-to-fail attempt and let the next one take over. CPAN itself is mostly rather nice, though... when I must use perl, which is altogether too often, I appreciate it.
From: Paul Orrock Date: 18:16 on 04 Nov 2004 Subject: Re: fink David Champion wrote: > > CPAN itself is mostly rather nice, though... when I must use perl, which > is altogether too often, I appreciate it. > For those few CPAN modules not under debian package management dh-make-perl --build --cpan Foo::Blah is your friend and gives you debian packages that you can then put on all your other servers and just dpkg -i them :-) I've only ever known it fail when a cpan install would fail (usually due to some not installed C library but one apt-get later and away you go) Paul.
From: peter (Peter da Silva) Date: 17:58 on 04 Nov 2004 Subject: Re: fink Fink stores SOMETHING outside its tree. I restored /sw after a system crash and fink didn't work. I haven't bothered figuring out what. What about Darwinports? I keep meaning to look at it.
From: Matt McLeod Date: 00:28 on 05 Nov 2004 Subject: Re: fink On 05/11/2004, at 4:58 AM, Peter da Silva wrote: > What about Darwinports? I keep meaning to look at it. I've been playing with it the last few days. It's not unlike BSD ports (as one would expect), but it has ports that are broken, have been broken for months, and don't seem likely to ever be fixed. It also has a lot less stuff covered than Fink. Fink is a long way from perfect, but so far it seems to be about the best of a bad bunch. I still build plenty of things by hand, but with the sheer number of dependencies that any GUI application has these days it's useful to let Fink take care of the basics (all the gtk+ and gnomeish things, for example) in advance. Oh, and ports ain't perfect either. It's quite possible to get into a mess with them, too. Remember: it all sucks. Matt
From: peter (Peter da Silva) Date: 01:27 on 05 Nov 2004 Subject: Re: fink > [with] the sheer number of dependencies that any GUI application has these > days it's useful to let Fink take care of the basics (all the gtk+ and > gnomeish things, for example) in advance. Ah, well, I just don't even try building gtk-ish or gnome-ish stuff any more. Not having to deal with a Microsoft-style desktop environment is one reason I switched to OS X, so I'm certainly not going to import a Linux-based one unless I absolutely have to. Speaking of huge horrible toolkits... if they don't get Flashblock.xpi updated for the Firefox release candidate I'm going back to Safari. Yeh, the extensions are nice, but I miss my Services too much.
From: Matt McLeod Date: 01:51 on 05 Nov 2004 Subject: Re: fink On 05/11/2004, at 12:27 PM, Peter da Silva wrote: > Ah, well, I just don't even try building gtk-ish or gnome-ish stuff > any more. Not having to deal with a Microsoft-style desktop > environment is one reason I switched to OS X, so I'm certainly not > going to import a Linux-based one unless I absolutely have to. There are a very small number of gtk+ applications I care about. avidemux being the big obvious one. There's simply no suitable alternative to it on OS X so I'm stuck dealing with the dependencies. As it happens, Fink has avidemux covered, but it's a very old version and I can't be arsed figuring out how to update Fink's wossname to use something a little more reccent. So I let Fink build the old version, which gets all the dependencies in place, and then build the current release myself. Matt
From: Anton Berezin Date: 18:37 on 04 Nov 2004 Subject: Re: fink On Thu, Nov 04, 2004 at 07:10:18PM +0200, Jarkko Hietaniemi wrote: > (The only package management I have ever personally seen "just work" > was the BSD ports/packages system. It's like CPAN.pm, it just works. > Pull down the source, configure, and compile it. No fucking binary > installations. AFAICT Gentoo is similar for Linux.) Apparently pkgsrc of NetBSD works with OS X. Never tried it myself, though. \Anton.
From: David H. Adler Date: 22:49 on 04 Nov 2004 Subject: Re: fink On Thu, Nov 04, 2004 at 07:10:18PM +0200, Jarkko Hietaniemi wrote: > > > > What's wrong with the fucking mirrors? Why don't I just blow OS X away > > and install Debian instead? At least it has a functional packaging system. > > I just simply blow away Fink. Finks sucks rotten eggs. Through a very > thin straw. With big chunks in it. > > So far I think I have repeated the following cycle three times. > There won't be a fourth time. [snip tenth circle of hell] Thanks for saying that. People often tell me "why don't you just use fink to install that?" and I can't manage to get past "*sputter* You're joking, right??". Every once in a long while I'll try fink if installing something isn't going well with other methods, but generallyl, I'll avoid it like the plague. dha
From: David Wheeler Date: 18:34 on 04 Nov 2004 Subject: Re: fink On Nov 4, 2004, at 7:57 AM, Nicholas Clark wrote: > What's wrong with the fucking mirrors? Why don't I just blow OS X away > and install Debian instead? At least it has a functional packaging > system. All packaging systems suck. HATE HATE HATE! D
Generated at 10:26 on 16 Apr 2008 by mariachi