[theory]

Haven't used a mac for about three years now and just bought a MB 2.4Ghz

I used to use fink to install linux packages but now apple is supporting Macport....

What are the advantages/disadvantages of each?
Thanks

[theory]

no response at all?

[CharlesS]

MacPorts: works on Leopard

Fink: doesn't work on Leopard

Winner: MacPorts.

[Simon]

I have fink and I have been using it for years now. I don't know if this is actually the case, but I get the impression development has slowed down a lot. It's been ages since the main fink package has been updated and I also don't see many new binary packages released either.

From Fink - Home
Status
Fink 0.8.1 was released on 15 June 2006...
10.5 Support: A binary installer for 10.5 is not yet available.

I haven't ever tried out MacPorts. Any opinions on it?

[CharlesS]

MacPorts works, except when it doesn't.

It's no worse than Fink was back in the days when it actually worked on the current OS.

The thing that irritates me about MacPorts is that all the dependencies have to be stuff that it installed, and I don't see why it can't just check /usr/lib, /usr/local/lib, /usr/include, /usr/local/include, etc. to see if the dependency it wants might just already be on the system. It's annoying when MacPorts won't install gtk2 because it depends on perl, and for some reason it's choking on Perl, even though OS X of course already comes with Perl installed, and it's the same version that MacPorts wants.

Most other stuff I've installed with MacPorts has worked fine, though.

[besson3c]

Originally Posted by CharlesS 

MacPorts works, except when it doesn't.

It's no worse than Fink was back in the days when it actually worked on the current OS.

The thing that irritates me about MacPorts is that all the dependencies have to be stuff that it installed, and I don't see why it can't just check /usr/lib, /usr/local/lib, /usr/include, /usr/local/include, etc. to see if the dependency it wants might just already be on the system. It's annoying when MacPorts won't install gtk2 because it depends on perl, and for some reason it's choking on Perl, even though OS X of course already comes with Perl installed, and it's the same version that MacPorts wants.

Most other stuff I've installed with MacPorts has worked fine, though.

It doesn't check those paths because the MacPorts have no way of assuring that these binaries and libraries have not been altered by Apple, and it generally doesn't make a good test environment to be linking to stuff in and outside of the sandbox. Additionally, many of the libraries that Apple has provided are old, and one reason to use MacPorts and/or Fink in the first place is for updating these very libraries for testing and/or security reasons.

To answer the original question, I prefer MacPorts, but really, if you want to be working with open source software in this manner you would be better off installing Ubuntu on a separate machine or in a virtualized environment. There have been countless occasions when I have run into a wall with MacPorts, as will you, no doubt...

[CharlesS]

Originally Posted by besson3c 

It doesn't check those paths because the MacPorts have no way of assuring that these binaries and libraries have not been altered by Apple, and it generally doesn't make a good test environment to be linking to stuff in and outside of the sandbox. Additionally, many of the libraries that Apple has provided are old, and one reason to use MacPorts and/or Fink in the first place is for updating these very libraries for testing and/or security reasons.

Well that's great, except that Apple's version of Perl apparently isn't old, since I checked the version on OS X's perl and it turned out that it had the same version number as the one MacPorts was failing to install. Furthermore, I'm thinking that the Perl that came with OS X would probably have a better chance of working than the Perl that MacPorts refuses to install because it chokes on "Staging into destroot".

[besson3c]

Originally Posted by CharlesS 

Well that's great, except that Apple's version of Perl apparently isn't old, since I checked the version on OS X's perl and it turned out that it had the same version number as the one MacPorts was failing to install. Furthermore, I'm thinking that the Perl that came with OS X would probably have a better chance of working than the Perl that MacPorts refuses to install because it chokes on "Staging into destroot".

I'm simply explaining the design decision here, which on the whole is sensible. I realize that there are instances where it is not ideal.

[theory]

Thanks for your input
I guess if the binaries are not available for 10.5 I'll be sticking with macport because that was the only real difference between the two packages for me.

Thanks guys

[besson3c]

Just so you know in case you need to do a Google search or something, Macports is plural.

[blackbird_1.0]

Is there a good GUI front end for working with macports?

[besson3c]

God no, why would you want one anyway?

[Chuckit]

Originally Posted by besson3c 

God no, why would you want one anyway?

Because it isn't 1975 and most people these days use GUI?

[besson3c]

Originally Posted by Chuckit 

Because it isn't 1975 and most people these days use GUI?

And exactly what benefit would a GUI tool offer for a tool that is through and through designed to be a CLI tool? If MacPorts were a binary installer like apt-get, you could make an argument to develop something like Synaptic, but as it stands users have to be aware of things such as variants, activation, and many packages that don't install cleanly. There is a GUI tool for Fink called Fink Commander, but I don't get the sense that many use it for the same reasons.

Dude, you really need to get out of your little Mac bubble and talk to people who administrate Unix systems to learn that the command line environment is bread and butter to them. They don't use GUIs on their servers, nor do they want to be hampered by them. MacPorts has many potential uses, but one of them is definitely testing open source software for administrators and developers. This is perhaps why, AFAIK, there is still no consumer-friendly binary install option and an extensive binary repository to go along with this.

[besson3c]

On top of this, to many Unix users, GUIs are 1975 in the sense of them being backwards and undesirable on servers. It all depends on what you are doing with the machine.

[Chuckit]

Originally Posted by besson3c 

And exactly what benefit would a GUI tool offer for a tool that is through and through designed to be a CLI tool?

The same benefits a GUI generally offers — for instance, it has a smaller learning curve, it's easier to remember if you don't use it often, and it offers greater interface consistency.

Originally Posted by besson3c 

If MacPorts were a binary installer like apt-get, you could make an argument to develop something like Synaptic

Last time I checked, neither apt-get nor Synaptic was just a binary installer.

Originally Posted by besson3c 

but as it stands users have to be aware of things such as variants, activation, and many packages that don't install cleanly.

This will be true whether or not you're using a GUI. And for people used to GUI, it could be less confusing with a more familiar interface. I don't see how this is germane.

Originally Posted by besson3c 

Dude, you really need to get out of your little Mac bubble and talk to people who administrate Unix systems to learn that the command line environment is bread and butter to them.

I need to get out of my little Mac bubble? This is a Mac site, and most of the users are home or business users rather than server administrators. Coming here and treating everybody as though they're a Unix administrator is about as reasonable as me going up to a Unix administrator and going, "Dude, just use OS X! It's totally easy!"

[besson3c]

Originally Posted by Chuckit 

The same benefits a GUI generally offers — for instance, it has a smaller learning curve, it's easier to remember if you don't use it often, and it offers greater interface consistency.

No it doesn't, you still have to learn about variants, activation, and dealing with problems whether you are using a GUI or not. All it would do is allow you to click on an icon to do each of these things rather than type in "port search <whatever>", or "port activate <whatever>". The whole point of MacPorts is to automate the compiling and installing of these apps, so there is really nothing more to automate, and little point in attempting to automate or override the automation already provided by MacPorts.

Interface consistency? Huh? Most of the ports in the collection are not GUI tools, so what point is there in worrying about interface consistency with OS X when once you actually start using the software you are installing you throw out these conventions anyway?

Chuckit, you are clearly a deeply entrenched Mac user, but it is extremely arrogant to just insist that the rest of the computing world ought to be identical to your narrow view.

Last time I checked, neither apt-get nor Synaptic was just a binary installer.

Then you weren't thorough enough in your checking, as neither of these tools compile source code, but install binary packages via the dpkg tool.

I need to get out of my little Mac bubble? This is a Mac site, and most of the users are home or business users rather than server administrators. Coming here and treating everybody as though they're a Unix administrator is about as reasonable as me going up to a Unix administrator and going, "Dude, just use OS X Server! It's totally easy!"

Why is it unreasonable for me to think that you'd want to use the software installed by MacPorts the same way the vast majority of the world does?

[Chuckit]

Originally Posted by besson3c 

No it doesn't, you still have to learn about variants, activation, and dealing with problems whether you are using a GUI or not.

Precisely. These issues exist with or without a GUI, so they aren't valid arguments against having a GUI.

Originally Posted by besson3c 

All it would do is allow you to click on an icon to do each of these things rather than type in "port search <whatever>", or "port activate <whatever>". The whole point of MacPorts is to automate the compiling and installing of these apps, so there is really nothing more to automate, and little point in attempting to automate or override the automation already provided by MacPorts.

Who said anything about automating anything? It's simply an alternative interface that fits some people's usage better.

Originally Posted by besson3c 

Chuckit, you are clearly a deeply entrenched Mac user, but it is extremely arrogant to just insist that the rest of the computing world ought to be identical to your narrow view.

On the contrary, that's what you are doing. Somebody expressed a desire for something, and because you and your Unix administrator friends aren't interested in the thing he wanted, you essentially brushed off his wish as invalid. I'm not saying Linux weenies have to give up their command lines — I'm just saying that some people like GUIs, and they're people too.

Originally Posted by besson3c 

Then you weren't thorough enough in your checking, as neither of these tools compile source code, but install binary packages via the dpkg tool.

Debian.org agrees with me.

[besson3c]

Debian does not agree with you, as apt-get install is what Synaptic does by default, and this command installs binary packages. The default documentation has people doing apt-get installs via the command line as well, for those that don't want to use Synaptic. apt-get source is for people that want to download the source and build it with their own compile-time options, which is an option, but not the default behavior.

Regarding the rest of your post, whatever, maybe I was too brash in blowing off wanting a GUI, but I still don't see much point to it. It's sort of like having a GUI tool to do pings or traceroutes for you, there is no compelling advantage.

[CharlesS]

Originally Posted by blackbird_1.0 

Is there a good GUI front end for working with macports?

Yes.

Two, in fact.