On Apr 05 08:25:49, Bradley Giesbrecht wrote: > On Apr 5, 2012, at 12:00 AM, Jan Stary wrote: > > > Again, this is not entirely true: the proper way for a port to > > not accidently pick up unwanted dependencies is to say --disable-whatever > > in the Portfile (and yes, I have run into that problem in ports > > I maintain). Not all ports provide a way to declare this, so > > you make sure it doesn't happen by removing /usr/local altgether, > > or making the user remove his /usr/local, which you will agree is > > a pretty extreme measure on a UNIX system. > > Simply put, MacPorts does not "SUPPORT" /usr/local in the sense that if you > ask for help from MacPorts we are going to ask you to move /usr/local out of > the way rather then tediously work though the contents of /usr/local. Our > resources are better spent on other tasks.
I respect that. However, I believe that if a port chokes on picking up some unintended dependency it found in /usr/local (or anywhere, for that matter), it is that port's problem: I don't think it's /usr/local's fault being there - I think it's the port's defect geting confused by that. Hence in terms of the (limited) resources, I believe it's the port maintainer's job to rectify this by actually fixing that (broken) port so that it no longer gets confused. I am willing to help this with ports that interest me. Is there a way in trac to specifically select the ports that have this problem? (Or is there even a keyword for that, such as 'usrlocal', 'externalconflict' or whatever?) Jan _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users