Mono Adds Mac OS X Package

Good news for those of you who've went through the pain of trying to get Mono installed on Mac OS X: the team has quietly added a Mac OS X package. If you previously installed to /usr/local, however, be aware that the packaged version installs to /opt/local and adjust any paths accordingly. The Beta-1 Windows installer has also been fixed; download it here.

Comments

Is .Net on OS X a Good Thing?

[mr_tap]

I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?

Don't mean to be a whiner of course :)

Explanation of /opt/local and /usr/local

[Anonymous Coward]

Would someone who isn't feeling too cranky explain the usage of /opt/local versus /usr/local please? I would like to understand the differences in the organizational concepts. As it is now, I just have irritation at the software that installs in the location I am less "familiar" with. Thanks.

Re:Explanation of /opt/local and /usr/local

[sleepypants]

Back in my slackware linux days, I always treated /opt as the location to install whole application trees, kind of like the "Program Files" directory in Windows. So if I download Mozilla, which untars into a "Mozilla-1.6" directory or something, I put it into /opt.

Of course, if I was using slackware's 'official' package of Mozilla, it would probably put all the binaries in /usr/bin, all the libraries in /usr/lib and so on. But for downloading and trying out nightly builds or betas, I would always use /opt.

/usr/local mirrors the structure of /usr (i.e. has bin,lib,share,src,etc.) so it was the place to install software that followed that structure.

Finally. . .iFolder

[Aiua]

I am excited about this quiet release. First, it opens up the possibility of compiling Novell's OSS iFolder on Mac OS X. Second, 60% of the computers in my company run Mac OS X, allowing for greater compatability between the remaining 40%. Third (and relating to the first), there was a recent evaluation of deploying iFolder company-wide, and the missing Mac OS X support was a critical issue. Now, the chances of the deployment happening have increased with the relase of Mono for Mac OS X. This should be great news for Apple fans.

Re:Aha!

[Smurf]

If you can't build a package that understands its own paths, and is re-locatable to any location, then its -not- finished, and you shouldn't release it.

I agree that all packages should be re-locatable. Unfortunately there are lots of *excellent* Unix/Linux and (gasp) Windows applications that are path dependent. I agree that they should be fixed when porting them to OS X, but meanwhile I prefer to have them even if they are "the result of laziness".

OSX is a Unix for Users. Use it that way!

Yes, but please don't break Unix in the process. Linking /proc to ~/proc is a terrible idea. MacOS X is finally a good multiuser system. Finally, all the members of a family or a workgroup can have their files in their own accounts without creating chaos and endangering the system. That's the goal of the users home directories.

By linking proc to ~/proc, you will limit the use of Mono (or whatever is installed in /proc) to one user (unless you duplicate it in every user account). Programs that should be available to all users should NOT be installed in a particular user's directory. That's a terrible practice. If you are so convinced in thinking different(ly), link it to /Users/Share/proc, but then again you have an absolute path.

Whose "utter"?