> On Aug 29, 2017, at 18:54, db <iams...@gmail.com> wrote: > > On 29 Aug 2017, at 23:24, Ryan Schmidt <ryandes...@macports.org> wrote: >> The best practice is not to do that. We don't support it. It can cause you >> problems that we don't want to spend time investigating, because they >> wouldn't be problems if you hadn't also used a second package manager. > > You already made the same point in the list years ago. > > Could you please summarize the problems one could encounter?fr > > Aren't these actually only related to homebrew using /usr/local/? >
They're related to using anything that might conflict with MacPorts, or any library that MacPorts uses, that's kept under /usr/local. So it's not just homebrew, it's anything that installs potentially conflicting items into /usr/local. (I'm told that some commercial software like the command-line tools for Parallels and VirtualBox, that sadly install into /usr/local, are unlikely to be a problem, presumably since they're only installing script wrappers around binaries elsewhere (in their application bundles), or at worst binaries with non-conflicting names, but not libraries or other more problematic objects, in /usr/local. But other things, including any commercial software that made the questionable choice to install libraries in /usr/local, is asking for problems.) AFAIK (others know better), that's because it's virtually impossible to purge all references to /usr/local from everything that MacPorts builds (or from Apple-provided software and libraries that it must use, at least to build its own toolchain). Therefore, it becomes just about impossible to assure that nothing will find the wrong version of especially libraries and shared objects from /usr/local. The trace mode has been said to be a mostly-effective workaround, at the cost of a considerable performance penalty, esp. when building a port from source. I do have a /usr/local on my boxes, but nothing I can't live without briefly is in it, and I move it out of the way whenever I run "port install" or "port upgrade". If I don't, I have problems too. Ideally I'd clean out from there anything that doesn't really have to be in there, but I'd have to put up with some breakage until I tracked down everything that has problematic files in there, and rebuilt it to use e.g. /opt/site or something like that instead of (like most typical ./configure; make builds) defaulting to /usr/local. /usr/local is a legacy dumping ground for stuff that''s probably not from the OS vendor - ideally, stuff that's site-specific only, not commercial or prepackaged software, but there are those who violate that rule. But a single dumping ground clearly will have conflicts; the newer, safer convention is distinct subdirectories of /opt, for each package or set of commonly managed packages; thus, MacPorts by default uses /opt/local, XQuartz uses /opt/X11 (for the stuff that's not elsewhere), etc.
signature.asc
Description: Message signed with OpenPGP
