- #UNINSTALL MACPORTS EL CAPITAN HOW TO#
- #UNINSTALL MACPORTS EL CAPITAN INSTALL#
- #UNINSTALL MACPORTS EL CAPITAN UPGRADE#
- #UNINSTALL MACPORTS EL CAPITAN SOFTWARE#
#UNINSTALL MACPORTS EL CAPITAN SOFTWARE#
That seems to kind of conflict with what you quoted "Large software packages must not use a direct subdirectory under the /usr hierarchy.", unless they mean a vendor-specific directory rather than "/usr/local". It says "The /usr/local hierarchy is for use by the system administrator when installing software locally."
#UNINSTALL MACPORTS EL CAPITAN UPGRADE#
> Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. It needs to be safe from being overwritten when the system software is updated. > The /usr/local hierarchy is for use by the system administrator when installing software locally.
#UNINSTALL MACPORTS EL CAPITAN HOW TO#
If you deleted it before SIP, but object to its absence now that SIP applies to the directory where it lives.I'm not sure how to help. The real question is why you deleted /usr/local in the first place. You should reboot to securely change nvram settings that will allow you to manipulate the protected zone of the file system (including /usr) because this concession to inconvenience saves you from privilege escalation attacks. That's a separate issue from the current thread, but OK. If Linus or the FHS changed their ways in this, there would be outrage. The security implications of "any other way" are massive.ī. Every standard that exists, including the principle of least surprise, is emphatic on that point. usr/local has never ever been writable by a nonprivileged user. However, I find that most of the disagreements I had with the MacPorts folks just haven't shown up with Homebrew.Ī. Homebrew, for better or worse, makes it much easier to make local changes to recipes, if you disagree with what the devs choose. I understand there are trade offs here, but the ones the MacPorts devs chose were not the ones I would have wanted. This appears to be a choice that the MacPorts devs made explicitly, since standard source builds of SDL don't do that, and the standard SDL binaries don't do that. For example, it used to be the case (and may still be) that LibSDL built under MacPorts would hard-code the absolute build path used to build it into the shared object, so that the frameworks wouldn't work if you moved them (e.g., if you wanted to use the frameworks to distribute an SDL-based game to your friends). One issue is that the MacPorts built versions of things don't always integrate in a nice way with other parts of the system. I realize this is anecdotal, but my experience has been much more like robbles' than mapgrep's. (And I know that's harsh but for a long time they trashed Macports right in their tagline - "Is MacPorts driving you to drink?" - which just seemed gratuitous.) My bias here is that I'm a longtime happy Macports user who has tried to use homebrew repeatedly, encountered lots of failed recipes, and gone back to Macports, shaking my head at all the hype around homebrew and the fact that is has somehow become a defacto developer default despite some really sloppy, poorly thought through practices. But you don't get key components changing out from underneath your packages due to an Apple System Update.
#UNINSTALL MACPORTS EL CAPITAN INSTALL#
Macports really only depends on a slice of Xcode from time to time updates will fail to install until you open Xcode and accept whatever new license Apple has bundled with it. But then it is much more fragile when your system updates.
Homebrew offers a much faster initial install because it leans on OS X libraries for various things. The downside is that it takes forever to install the first few packages. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. Macports, meanwhile, continues to work quite well because it 1.
0 kommentar(er)
