On Apr 22, 2008, at 2:40 AM, Ryan Schmidt wrote:
On Apr 21, 2008, at 5:03 AM, Mike McAngus wrote:
On Apr 21, 2008, at 12:17 AM, Ryan Schmidt wrote:
On Apr 20, 2008, at 7:25 PM, Mike McAngus wrote:
I did not consciously install anything in /usr/local. Looking
in there, I see
* ClamXav directory. I could probably replace ClamXav with
clamav from MacPorts if I was willing to give up the UI.
* A "SourceGuard" directory which I don't recognize. All of
its files have Created, Modified and Accessed dates of 9/3/03.
These are not a problem. It's only things installed "directly"
in /usr/local (that is, that were compiled with --prefix=/usr/
local or which install into prefix /usr/local by default) which
can cause problems.
* A bin, include, lib, man and share directory. There are many
files in those directories.
These are the potentially problematic files, especially the bin,
include and lib directories.
OK. So how do I determine which of the 66 files in those three
directories are problematic?
Different ports have different dependencies. Suppose you want to
install port A, and it depends on port B which depends on port C.
But you've manually installed an older version of C in /usr/local.
I reiterate, I have not consciously installed anything in /usr/
local. Anything that is there was put there by some application in
some .dmg that I installed. I'm a Java web developer, and I have a
separate disk drive named Projects where I do all my personal coding.
MacPorts will dutifully follow the dependency chain, and into its
prefix (usually /opt/local) it will install C, then B, then A, only
when it tries to install B, the compiler will probably find some
parts of the older C in /usr/local, because the compiler always
looks in /usr/local and we don't know how to tell it not to. But it
may still find other parts of the newer C in /opt/local. If the
versions don't match, this may result in a failure to build B, for
example if B is trying to use new features of C present in the /opt/
local version but not in the older /usr/local version.
To resolve this problem, you must remove the files of C that are
in /usr/local. There is no general-purpose automated way to
discover which files belong to C. You have to dissect the
installation script for C, ask the authors of C, etc.
Or in your case the file in /usr/local wasn't conflicting with one
provided with another port but with one provided by the system.
In other words, if you want to mix software in /usr/local with
software in MacPorts, you have to know what you're doing, and it's
too much effort for us (or at least for me) to support any
configuration where MacPorts users also install software in /usr/
local.
When it comes to Java, Javascript and HTML, I know what I'm doing.
When it comes to manipulating files in magic *nix directories, I just
don't do it without explicit instructions. I have no recollection of
any explicit instructions involving /usr/local
And, how do I ensure that if I make files in those directories
unavailable I won't break something else?
You need to know what software you installed into /usr/local and
what you use it for.
Until this past week I had no idea that I had installed anything in /
usr/local/. I know what ClamXav is, but not what SourceGuard is or
how it got there (and I'm researching what I have to do to get rid of
it). Now, I have files in /usr/local/bin, /usr/local/lib and usr/
local/share and I don't know what uses them.
Hopefully the software you installed in /usr/local is also
available with MacPorts, so you can move /usr/local aside, install
the software you need using MacPorts, and that's it. If ports do
not exist, you can make or request them.
When I was moving to MacPorts, I moved my /usr/local aside and as I
found things that were broken I installed the appropriate ports.
Since the /usr/local/clamXav directory has its own bin, include and
lib directories, I've decided to move everything else under /usr/
local to a new /usr/local.hold directory. Now I get to wait and see
what breaks. Joy!
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
