Hot answers tagged macports
MacPorts 1.9.0 added the sqlite portdbformat and MacPorts 2.0.0 dropped the old flat format. The sqlite port DB format is the default for new installations; old installations that were upgraded to 1.9.x will continue to use the flat format1. You can convert a 1.9.x flat system to the sqlite format by upgrading to MacPorts 2.0 or by changing the portdbformat ...
Definitely Homebrew. I started with Fink, then switched to MacPorts (happier), then Homebrew (much, much happier). These are my reasons for using each (a pro list if you will): Fink Apt-based - feel right at home if you come from a Debian-based environment Binary packages - packages are available as binaries so no long compile times. Practically though ...
I use HomeBrew too and can confirm it's totally safe. Quoting the Installation page on the official HomeBrew wiki: Do yourself a favour and pick /usr/local It’s easier /usr/local/bin is already in your PATH. It’s easier Tons of build scripts break if their dependencies aren’t in either /usr or /usr/local. We fix this for Homebrew formulas ...
port contents installed_port_name
Fink has been around since at least 2001. Fink and MacPorts are package managers that want to be "orthogonal" to the system, that is, they install their own version of python, perl, libraries, compilers, etc. in own trees (/sw for Fink, /opt/local for MacPorts). The reason for this is that they have no control what Apple does with its software, and it ...
MacPorts It is more independent of Mac OS X, this means MacPorts will just ignore many of the system libraries and softwares that already available in Mac OS X and pull its own one instead, which could be slower when the utility you install requires some set of large libraries and softwares. But this kind of choice is safer because the packages you ...
The problem is that your version of MacPorts was not built on Mavericks and assumes the tools that were there when it was installed are still available. Since this is no longer the case, you should re-install MacPorts, which will automatically fix this issue. Since there is no binary installer for Mavericks at the moment, you will have to build from source ...
Alternatives for MacPorts Homebrew Uses OS X binary versions when available Compiles OS X optimized versions Compiling usually faster than with MacPorts Easy to use, e.g. to install wget: $ brew install wget Tries to separate already installed software from what is installed through brew … … while taking advantage of already installed software and ...
Just to add some of my own thoughts that seem true-ish circa late 2014 at least. Homebrew, as of a couple of years ago, definitely has the upper hand in terms of mindshare. You'll find a lot of blogs with people talking about how much happier they are with Homebrew - usually because of the whole "MacPorts pulls in the whole world" vs "Homebrew makes use of ...
The MacPort documentation advises to use your Terminal and type: sudo port -fp uninstall installed and with this command, all remaining items will be deleted: sudo rm -rf /opt/local sudo rm -rf /Applications/DarwinPorts sudo rm -rf /Applications/MacPorts sudo rm -rf /Library/LaunchDaemons/org.macports.* sudo rm -rf /Library/Receipts/DarwinPorts*.pkg sudo ...
Yes, you can try Homebrew
It is usually better to keep permissions as strict as possible. Keeping /usr/local owned by root means that only processes that run as root/sudo (or ask for admin user via the Apple authorization dialog box) can write to this area. Thus, a process download has to ask you for a password before corrupting files there. But as you say, it makes adding new ...
sh --version is probably the same as /bin/sh --version. If the current shell is bash, you can see its version with echo $BASH_VERSION. If you change the default login shell with chsh, you can keep Terminal's default shell as the login shell. sudo port install bash Add /opt/local/bin/bash to /etc/shells chsh -s /opt/local/bin/bash Open a new tab and check ...
If you use contents, it will tell you where they are.
Unless you performed a custom installation of MacPorts everything installed by MacPorts is located conveniently at /opt/local if you perform a directory listing at that location you should see the structure for port installed programs which should be installed in bin or sbin directories. user$ ls bin etc include lib libexec man sbin ...
For what it's worth, /usr/local is not considered a "system" folder by OS X, and on a brand new Snow Leopard install that folder is empty. Any root-owned stuff in that folder is a result of sudo make install on other software, or giving your password after double-clicking on a .pkg that wants to dump stuff into /usr/local. Owning /usr/local has "worked for ...
Macports select can change it back. The current macports does it using the port select command - older versions had python_select To see the possible pythons run port select --list python From that list choose the one you want and change to it e.g. sudo port select --set python python25-apple
port search $TERM The MacPorts Guide is really useful for these sorts of things.
From the docs: The uninstall action will uninstall an installed port. %% sudo port uninstall vile Note To also recursively uninstall the ports that the given port depends on, use the ‑‑follow‑dependencies flag. This will not uninstall dependencies that are marked as requested or that have other dependents. To recursively ...
Try to do something like pkgutil --file-info /usr/include/eigen3/your.file That will return where the file comes from... For instance (I do not have eigen3 in /usr/include): $ pkgutil --file-info /usr/include/cups/ppd.h volume: / path: /usr/include/cups/ppd.h pkgid: com.apple.pkg.DevSDKLeo Let me add, Macports would not install anything in ...
Did you run sudo xcode-select -switch /Applications/Xcode.app? This message: error: can't exec '/Developer/usr/bin/xcodebuild' is telling you that your system is looking for xcodebuild in `/Developer/usr/bin/' but as of Xcode 4.3 (the one that's installed from the App Store) it's located in the Xcode.app bundle which is in /Applications. Edit In a comment ...
Looks like they've already got a workaround: brew rm libpng brew install libpng --universal Then brew install wine. Worked for me a few moments ago. See the linked github issue for more details.
When you call /bin/bash with only one argument, you can only run scripts. Not binaries. This has nothing to do with the tools you installed, it's just the behavior described in the man page. /bin/bash -c ls should do what you want.
My dirty hack was a symlink to system tar command. sudo ln -s /usr/bin/tar /usr/bin/gnutar
As stated here https://trac.macports.org/wiki/ProblemHotlist, you need to run: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer
This is my essential list, in the order that I install them. arping watch wireshark figlet git-core gnupg ipcalc lynx +ssl minicom mtr ncftp nmap pstree pwgen p0f ssldump stunnel tcpflow unrar w3m wget
The correct answer is sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql5.plist And you start it with sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist Thanks to kh13org for the pointer.
I just compile from source, since all of the important programs build easily on Mac OS X these days. Here's a great article on the advantages of building your own stuff vs. using package managers. Having said that, here's my quick list: Mercurial Git GNU Privacy Guard 1.4.x ffmpeg MySQL Best directions I've seen for building 32 or 64-bit MySQL on Mac OS ...
Try installing Scala 2.9 sudo port install scala2.9 … or Scala 2.10 sudo port install scala2.10
Running mdfind -name tclIndex on Mac OS X 10.6.8 shows that the path to tclIndex is /System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts/tclIndex! Anyway, if there is a pristine MacPorts 2.0.3 system running on Mac OS X 10.6.8, meld gets installed without any (serious) complaints. The same goes for koffice provided that it can use an ...
Only top voted, non community-wiki answers of a minimum length are eligible