OK, here’s the “fun” part of the upgrade. Fixing MacPorts. Fortunately MacPorts installs stuff in mainly two places. /opt and /Applications/MacPorts. So that makes dismantling the old stuff relatively easy. Usually I start by moving the /Applications/MacPorts directory to the desktop and then simply renaming /opt to /opt.old so as to keep everything around. (Also note that I did a total disk backup prior to installing Snow Leopard in case of real catastrophic mistakes)
To get rid of everything (and some of these directories are legacy) do the following:
sudo rm -rf \
/opt/local \
/etc/manpaths.d/macports \
/etc/paths.d/macports \
/Applications/DarwinPorts \
/Applications/MacPorts \
/Library/LaunchDaemons/org.macports.* \
/Library/Receipts/DarwinPorts*.pkg \
/Library/Receipts/MacPorts*.pkg \
/Library/StartupItems/DarwinPortsStartup \
/Library/Tcl/darwinports1.0 \
/Library/Tcl/macports1.0
Download the Snow Leopard version of MacPorts from their installation page. Run the installer off the dmg.
Sync MacPorts via
sudo port -v selfupdate
Fix your .bash_profile and make sure that your path includes the MacPorts stuff. (You can decide if you want the Apple stuff or the MacPorts stuff in /opt privileged by setting in first in the PATH) My own PATH is set as the following:
export PATH=/opt/local/bin:/opt/local/sbin:$HOME/bin:$PATH:/usr/local/bin:/Library/MySQL/bin
Set the MANPATH in the same place. Mine is:
export MANPATH=`/usr/bin/manpath` export MANPATH=/opt/local/share/man:$MANPATH
Note that first export actually runs a script to get the path. The kind of quotes are important.
Finally install your software. I find this updating of MacPorts a great time to decide what I really use. Often I installed stuff thinking I’d use it only to realize I’ve only run it a half dozen times. (Yeah, a lot of X11 apps including the entire Gnome install!) On a laptop that savings adds up.
I’ll offer a bit of an explanation for each package I install. I’m not saying you ought install all of these. Nor that there aren’t other good ones to install. Just that these are the ones I find useful. Let me know if I screwed up anywhere.
sudo port install mysql5 sudo port install ManOpen sudo port install Lingon sudo port install Pallet sudo port install nmap sudo port install wget sudo port install mercurial sudo port install git-core sudo port install subversion sudo port install rsync sudo port install bison sudo port install flex
mysql5: The latest mysql. Really, you do need this although a lot of my friends swear by postgres. (Edit: I’d suggest building MySQL from source. I have a followup post on how to do it)
py-mysql: Since py-mysql isn’t working right with easy_install (see Friday’s post) I installed it via MacPorts. Normally I don’t like to install anything Python via MacPorts due to questions of what module is in what install of Python. I’ll let you know here of any problems I encounter. (Edit: Not working right with 2.6 – the version I installed was for an earlier version I discovered)
ManOpen: This is my favorite man entry reader. (Oddly, it didn’t compile right the first time I installed it) I also place in my .bash_profile an alias from man to ManOpen.
alias man=openman
Lingon: A must have and a bit easier to keep up to date via MacPorts rather than downloading directly. (Make sure you don’t accidentally have two copies, as I did for a while, as it can get confusing) I use this a lot to run scripts at certain times or under certain events (like disk insertions).
Pallet: A gui for installing or removing ports. I honestly still use the terminal most of the time but this is nice to have.
nmap: A great port scanning tool. I honestly use this a lot on my local network to find the ip address to ssh into. It’s very nice for rarely accessed machines or machines using dhcp. This is the command I use the most:
nmap -p 22 192.168.1.1-255
wget: Pretty similar to curl but a little simpler for downloading. I find I use it most of the time over curl.
mercurial: My versioning control system of choice at the moment. I confess I’m still learning it.
git-core: For those repositories I need to access. I still like things about git even though I’ve decided on mercurial.
subversion: ditto.
rsync: I like to have the latest version without mucking around with the Apple version.
bison: I have some specialized scripting languages for indexing and data analysis that I wrote and maintain using flex and bison.
flex: ditto.
There are a few others I install. But that’s all I’m installing today. I saved about 10 gig, I noticed, updating MacPorts. Not bad. I have about a half dozen ports I might install. Once MacFuse is uptodate in MacPorts (it’s 1.7 right now, but 2.0 is what runs under SL) I might add that to the mix.
Related posts:
- Upgrading to Snow Leopard Part 4: MySQL
- Paths and ManPaths in Leopard
- Upgrading to Snow Leopard Part 1: Python
- Upgrading to Snow Leopard Part 2: Minor Tips
- Upgrading to Snow Leopard Part 6: 64bit vs. 32bit
- MacPorts & Python
- Upgrading to Snow Leopard Part 7: One Month Later
- Upgrading to Snow Leopard Part 5: The Python Gripes
.jpg)
#1 by Clark on 2009/08/31 - 8:53 am
py-mysql isn’t working in MacPorts for 2.6 either. Weird.
#2 by clark on 2009/08/31 - 9:07 pm
And building from sources isn’t working properly either. Urgh… This is getting annoying.
Edit: OK, building from source is the way to go. Check out my post on doing it.
#3 by Brett on 2009/09/02 - 12:16 am
Hey Clark,
Thanks for the guide. I have a question, have you had any luck getting PIL installed? I have been tearing my hair out and was wondering if anyone else came up with a solution for this.
Brett
#4 by Alex on 2009/09/06 - 8:06 pm
Another site I’ve stumbled across suggests using “sudo port upgrade –force installed” to force an upgrade of all installed packages. Does this actually work for anyone?
http://syntatic.wordpress.com/2009/08/30/macports-snow-leopard-upgrade/
#5 by fideli on 2009/09/10 - 9:57 pm
“Normally I don’t like to install anything Python via MacPorts due to questions of what module is in what install of Python.”
Hello, this confuses me. I figure that it would be better to install via MacPorts as much as possible, particularly when using the ports prefixed with the version of Python you’re using (i.e. py26-scipy). Am I mistaken? I’m new to Python and am eagerly awaiting for certain ports to be fixed in order to get back into it.
#6 by clark on 2009/09/10 - 11:19 pm
Basically you’re never sure sometimes which version of Python is running. You have to be sure that your Path from .bash_profile is set but that doesn’t always happen. Then you have libraries installed by commands like easy_install.
If you make sure /opt/bin comes before /usr/bin in your Path at all times and you are careful to just install modules with MacPorts then you should be fine. It’s just you have to be very careful otherwise unexpected things can happen.
#7 by Alex on 2009/09/14 - 9:30 pm
I’ve been using virtualenvs + virtualenvwrapper combination to solve the “what’s installed where” problem.
This means one only has to be careful about what version of Python is “it” when one creates a virtual environment. After that, you “workon” the virtual environment, and use easy_install to install packages into the virtual environment’s path.
I do not modify the default or MacPorts installs of Python beyond installing setuptools and virtualenvs.
PS: my previous comment about using “port upgrade -force installed” failed on a few packages, so I ended up going with Clark’s suggestion of simply removing MacPorts altogether and starting from scratch.
#8 by fideli on 2009/09/14 - 9:38 pm
Ah, I see. That would be a concern with easy_install. Does the MacPorts python_select port not take care of those issues?
#9 by clark on 2009/09/14 - 9:41 pm
MacPorts’ python_select should, one would think, deal with this. In my experience it doesn’t though. Indeed trusting python_select is what got me into trouble.
#10 by M on 2009/10/06 - 11:02 am
Basically the whole process of upgrade is well documented on MacPorts wiki:
http://trac.macports.org/wiki/Migration
#11 by Alex on 2009/10/07 - 4:24 pm
M: the “take off and nuke the site from orbit” approach means you don’t end up reinstalling cruft. It’s equivalent to moving the furniture to a different room when you do the vacuuming: it enforces a discipline of cleanliness.
Simply upgrading every package that you currently installed will result in your computer having dozens of packages installed which you used for one project but don’t use anymore. Or worse, you’ll have several versions of a package installed with different variants, none of which you actually use anymore (because you used to write in Ruby on Rails, then switched to Django, then switched to Perl with MOOSE, and now you’re using WebObjects).