On Sat, Jul 18, 2015, at 05:08 PM, Joshua Root wrote: > What do you mean by "port wouldn't recognize the change"?
What I was trying to do was fix a conflict between a port requiring libusb, while I have libusb-devel installed (since the libusb and libusb-devel ports necessarily conflict). I had changed all of my other ports to using either libusb* port, and other dependencies a while back; somehow overlooked this one. In the past, I would make the change to the Portfile and port would recognize it immediately -- meaning, I could issue the install or upgrade command on the main port of interest, and this indirect dependency would be determined and met correctly with just that simple edit. This last time, after updating to the latest SVN trunk/base, I made the change but port still complained about the conflict. With the rev-bump & upgrade, all was well again. I thought it strange, but then port sometimes does things like this & this one is really not a big deal. Another example is when doing "port info" on the new cmake variants -- where +docs internally defaults to using +python27 but the user can select +python34, and both of the +pythonXY variants require +docs. When I do "port info cmake +docs" if comes out correct, with the default variant of +python27 showing. If I do +python27, +docs does not show up even though it is required, nor are dependencies shown for the +docs variant. Looking at "port variants cmake", all of the requires and conflicts are correctly shown. Again, a minor thing, just a little confusing the first time I came upon it. - MLD _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
