New Fink Binary Distribution 0.5.2

dmalloc writes "The Fink Project community and contributors announced the availability of the Fink Binary Distribution 0.5.2, which adds binaries for KDE 3.1, Koffice 1.2.1, and Kdevelop 3.0a3, new documentation/manuals, and improved support for Apple's X11 Server along with speed improvements to fink itself. Download instructions are on the Fink site."

Comments

Include More Info

[avalys]

If we're going to make Slashdot into Freshmeat (which is fine with me, to a point), submitters should at least include information on what the program actually does!

Especially when the server is Slashdotted (admittedly not the case here) and the rest of us are wondering: "should I care about this?"

Re:Include More Info

[potuncle]

I'm no expert, but have found fink to be an awesome addition to OS X. It brings many (I think 5000+) software packages and apps from the UNIX/LINUX/BSD world to OS X. It can be a major selling point on OS X for UNIX/LINUX/BSD users. Now they can have the Aquaesqe goodness, along with the power and flexibility of UNIX/LINUX/BSD apps and libraries.

Re:Include More Info

[water-and-sewer]

I'm all for bringing Unix/Linux/BSD software to OSX; in fact the mere availability of Fink makes me far more interested in an iBook than I would've been otherwise. Stuff like Lyx, TeX, emacs, vim, and mutt make me believe I can have all the aqua goodness of an imac without sacrificing the applications I use the most.

But updating Fink for the purpose of upgrading Koffice is something I can not comprehend. I haven't been able to make Koffice useful for anything other than the simplest one page letters. The spreadsheet and presentation apps are difficult to use and Kword, while it's capable of much more, is still very difficult to use. If you've got a Mac, you've got Appleworks, which is a very respectable office suite. No, it's not full featured, but it's basically user friendly, and in my opinion it offers more functionality than Koffice. Koffice isn't why you should upgrade Fink.

Re:Include More Info

[Anonymous Coward]

If you've got a Mac, you've got Appleworks, which is a very respectable office suite.

Well, Power Macs and PowerBooks don't ship with AppleWorks, so the first half of that claim is incorrect.

As for the second part - have you used AppleWorks on OS X? It's totally horrible, and virtually hasn't seen an upgrade since 10.0 was released!

Re:Include More Info

[King Babar]

As for the second part - have you used AppleWorks on OS X? It's totally horrible, and virtually hasn't seen an upgrade since 10.0 was released!

AppleWorks is...fairly weak. But the "draw" component has saved my backside on a couple of occasions. If memory serves, the AppleWorks folks were originally the MacDraw people, and I think that's about the only thing that I like about the current package.

Fink and Mcafee virus

[nilepoc]

I have not been following fink that closely, but I remember a conflict exixting between Fink and Mcafee virus protection. (the service that comes with .mac) I have forgone updating my virus coverage as a result. Because I want to try fink out.

Coes anyone know if the conflict is fixed?

Re:Fink and Mcafee virus

[Anonymous Coward]

No, it's not fixed, and it's totally McAfee's fault. They have used Fink themselves in-house to create Virex 7.2's auto-update feature, however the way they've implemented it totally breaks both Fink and Virex.

This is not Fink's fault, and there is *nothing* they can do to fix it. Want to complain? E-mail McAfee.

Re:Fink and Mcafee virus

[Mikey-San]

The gist of the situation:

McAfee used Fink during the development of Virex, and as such, if you're using Virex and try to install Fink--well, you can't install Fink, so I won't finish that thought.

It's not a problem with Fink. Virex is causing the problem, and unfortunately, until McAfee get their act together, Fink and Virex can't be installed on the same machine.

Fink, when instaled, looks for /sw, and if it finds it, it doesn't install. This might look like Fink's problem, but in reality, it's Fink trying its absolute best not to do anything that might harm your machine. (They use /sw instead of other binary directories for the same reason.) Much applause to the Fink team for these conventions, I say. Developers looking out for users is always a good thing, even when some might think they [the developers] are being overly cautious.

Check out this thread for more discussion.

Re:Fink and Mcafee virus

[pcp_ip]

virex and fink are fine now. download 7.2.1 from mac.com.

to fix a messed up fink from 7.2 just:

fink reinstall openssl-shlibs dlcompat-shlibs curl-ssl-shlibs

and you're set to go.

Re:Fink and Mcafee virus

[CordMeyer]

Fink and Virex can't be installed on the same machine.

Yeah, but has anyone ever had a virus on OS X? Do they even exist?

I'd take Fink over Virex any day.

Re:Fink and Mcafee virus

[wtmcgee]

http://fink.sourceforge.net/news/

2003-04-16: Virex problem resolved

McAfee has released Virex 7.2.1, which no longer overwrites the main Fink directory /sw. Fink users should continue to avoid Virex 7.2.

Early reports indicate that upgrading Virex from 7.2 to 7.2.1 still leaves some problems however. If you upgrade Virex with Fink not installed, and subsequently wish to install Fink, you will need to delete the /sw directory by hand before installing. And if you upgrade Virex with Fink already installed, you should immediately run

fink reinstall openssl-shlibs dlcompat-shlibs curl-ssl-shlibs

to restore files which the Virex upgrade has deleted.

Re:Fink and Mcafee virus

[Hi Larry!]

I found it quite bad from McAfee to use fink and then screw all fink user with Virex.

Don't use if your default shell is /bin/zsh

[Sniffer]

The init.sh script pukes with /bin/zsh as your shell....

Re:Don't use if your default shell is /bin/zsh

[rdieter]

you probably shouldn't be changing root's shell either.

Re:Don't use if your default shell is /bin/zsh

[ZxCv]

Why?

I've heard this a number of times, mostly from an old Solaris admin I used to work with. Yet, in 8 or so years of administering all kinds of *nix boxes, I have yet to run into a single problem that was caused by changing root's shell. I can see being careful about it, but then again, you should be careful about everything you do as root. It seems to me that anything that relies on root having a specific shell is inherently broken software to begin with, and shouldn't be run as root at all.

I've administered everything from Solaris to FreeBSD to Linux and now Mac OS X, and I've used many shells for root among them, including ksh, zsh, csh, and bash. The day I'm forced to use a particular shell for root is the day I find a new operating system.

Re:Don't use if your default shell is /bin/zsh

[Anonymous Coward]

No, but init.sh must be sourced at the beginning of an interactive shell session, since it sets up the PATH and some other things that fink needs to function properly. Lets say I log in as an admin user, starts a terminal and type sudo fink install whatever, then it doesn't matter what root's shell is - but it is important that my zsh shell properly sourced the init.sh file.

Re:Don't use if your default shell is /bin/zsh

[dmalloc]

This issue has been addressed and the base files package has been updated. Ny running fink selfupdate or fink selfupdate-cvs you should get a new revision.

It is actually a bug in zsh, since it seems to spawn and internal process to do some globs and that leads to a wrongly escaped string asfaiu

Re:Don't use if your default shell is /bin/zsh

[rdieter]

Why?

Why ask why?

Seriously, there are many absolutely critical portions of the system that are simple (and not so simple) shell scripts, and these are only guaranteed/tested to work with the *default* shell. Messing with root's shell is only asking for trouble. Really.

Now, knowing this, if you still fell compelled to go and change it, by all means, go for it, but don't go complaining about things breaking as a result of your modification.

Re:Don't use if your default shell is /bin/zsh

[Anonymous Coward]

> Has anyone else noticed something like:
>
> prepend_path:2: no matches found: "${PATH##*:/sw/bin:/sw/sbin:*}"
>
> When using the z shell as opposed to the bourne shell for the
> interpretation of /sw/bin/init.sh ?

Yes, this has been discussed on one of the lists recently. It is fixed
in the sources and will soon be distributed in the form of a new
base-files package.

If you want to fix it yourself, it is easy: Edit your /sw/bin/init.sh as
follows:

In the two lines that start with

if ! eval test -z \"\${$1##*:$2:*}\"

escape all the asterisks: Replace * by \* (4 in each line).

Re:Don't use if your default shell is /bin/zsh

[ZxCv]

Seriously, there are many absolutely critical portions of the system that are simple (and not so simple) shell scripts, and these are only guaranteed/tested to work with the *default* shell. Messing with root's shell is only asking for trouble. Really.

Well, in that case, the script should be marked executable and the #! line should contain the proper shell to use. Or, perhaps just call the shell directly with the script as its argument? What's so hard about that?

My whole point was that if changing the default shell breaks the script, there is something inherently wrong in how the script is written and/or being run. In 8+ years, I've never seen a script break because of changing the default shell, but if I ever did, I would quickly start looking for a new OS.

Upgrade Instructions

[Anonymous Coward]

The link in the story is about how to download fink for your first time, not upgrade. If, like most people, you have a mix of binary (ie from apt-get) and source (ie from fink) packages in your fink distro, you'll want to do the following:

sudo apt-get update # new package descriptions
sudo apt-get dist-upgrade # download and install binaries (this takes a long time)
fink selfupdate # update fink itself
fink update-all # download, compile, and install source packages

If you have trouble, a fink index or fink scanpackages command can help out sometimes. The Upgrade Matrix or Upgrade page in the manual would have been better links for the slashdot article, imho.

avalys: If we're going to make Slashdot into Freshmeat (which is fine with me, to a point), submitters should at least include information on what the program actually does!

C'mon, now, thats not fair. Fink is more than just another program; it's a whole software distro. If they can announce new versions of debian and redhat, they can announce new versions of fink. This announcement really means new versions of hundreds of programs.

KOffice: glad to have you on board!

[Steve Cowan]

Koffice isn't why you should upgrade Fink.

KOffice may not be the best suite out there, but by providing an OS X port, there is a much stronger motivation to develop KOffice.

Everybody benefits: another title for the Mac, it's free (as in beer), expanded KOffice user base, yet another reason for Mac users to use Fink, freedom of choice.....

It's an exciting time to be a Mac user. I honestly would not be surprised to hear that applications are becoming available to Mac users faster than new apps are being developed for Windows. In other words, the list of Mac-compatible desktop software titles may be growing at a faster rate than the list of Windows titles.

Info yes, Freshmeat no

[fm6]

You're right about the "what is it" factor. Too many Slashdot articles assume that everybody has heard about Fink, or Joe, or Sesquipedialian Architectures.

But I don't think this kind of announcement duplicates anything at Freshmeat. (What's Freshmeat?) That site is for people who already run specific platforms, and are curious to see what's being developed for those platforms. But you don't have to be a OS X enthusiast to be interested in the doings of the Fink team.

Perl and Fink

[sco08y]

One problem I have is getting perl and Fink to behave. I don't think this is Fink's fault, but I've checked the site and haven't seen a very good solution.

For starters, if you upgrade Fink's version of perl, then all the old perl libraries will be binary incompatible. (And here, Apache + mod_perl counts as a "library" since it won't boot.)

Do I go and rebuild all my libraries? Or rebuild the default install of perl? Or muck about with @INC? I could do that... but it defeats the purpose of Fink.

Maybe it's safer to have multiple versions, and I can certainly uninstall Fink very easily, but it still seems to be a bit of a mess.

Even if you avoid the package manager and build everything manually Fink still saves a huge amount of time because all the annoying fixes are already there. But it's disappointing that we're not really that much better than Windows when it comes to simple issues like binary compatibility. (Honestly, how is it any different than DLL-hell?)

I'm *really* hoping that in the future, Apple is going to provide upgraded facilities for package management. My dream is that one day we'll have a utility that will analyze our system and all the little customizations we've made and get a full analysis, and the ability to easily turn things on and off... just like good old Extensions Manager, but universal.

Re:Perl and Fink

[Anonymous Coward]

The problem is not with DLL-Hell, the problem is with your path. One is trying to use the other's perl.

Simply make sure the /sw directories (et. al) are not in the path for your scripts where you want to use the system-perl.

On the other hand, why did you install multiple perls by the way?

I have only one perl installed, Apple's Perl, and everything works fine. One X11, Apple's X11, and everything works fine. One teTeX, the one that came with some OSX native LaTeX editing apps I use, and everything works fine.

No need for Fink's versions when you already have others installed.

Re:Perl and Fink

[sco08y]

Perl gets old quickly... for example, DBI is now frozen for 5.6.0, which is the version Apple ships.

I also like the IO filters and all that nice stuff in 5.8.

Probably more important than the bleeding edge is being able to run older perl scripts. There are still some perl 4 scripts out there, and I'm not sure I'm even familiar enough with stuff like globs to be able to get them running in perl 5.

You really can't assume that because something ran on an older interpreter that it will run on a newer one. You ought to see the hoops Java developers jump through... and many of them still ship entirely separate VM's.

Re:Perl and Fink

[sco08y]

Simply make sure the /sw directories (et. al) are not in the path for your scripts where you want to use the system-perl.


Maybe I should file a bug report on this, because I'd *like* to use fink's /sw/bin/init.sh, but it just appends everything. I think it ought to overwrite PERL_INC entirely. As it is, packages in /Library/Perl seemed to be showing up and that was causing all the problems.

So what I've done lately is just blast Apple's Perl (sudo rm -rf {/System/,/}Library/Perl) and build perl from scratch. (Use configure --prefix=/usr to put the new perl back in the right place... Apple has info.

I also want to see if I can overwrite Apple's Apache... then you have a nice set up where you have exactly the version of Perl you want, and exactly the version of Apache with mod_perl statically linked and all the modules built properly. Unfortunately, it goes against the "don't mess with Apple's distro" rules and I'm sure software update is going to break it horribly one day.

Blarrgh.

Re:FIXED!

[bursch-X]

Today Apple posted a link to an update for Virex on the .Mac site. Everything works fine now here!