[138727] trunk/dports/science/gr-fcdproplus/Portfile

[Michael Dickens]

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