On Wednesday October 26 2016 00:25:14 Clemens Lang wrote: Hi,
> The problem is that we don't see the difference. The code that procudes > the error is more or less > "source $filename" > which can fail either because the file isn't there, or because the code > in the file failed. Yeah. There could be a check if the Portfile exists to catch the 1st possibility, and some more information about the error (if there was one) could be useful too; the catch command can return a string with that information. > > PortGroup from the same directory as the main PortGroup, and that > > condition cannot hold for copies in the registry which all live in > > their own directory. > > So the behavior was actually correct. Yes. In fact, after fixing the offending code in my stuff I spent at least half an hour trying to figure which of the other recent modifications to my stuff could explain the error I ended up reporting. Has anyone been able to confirm this issue? For example: - port -n install foo configure.optflags="-Os -g" - port -nkvd upgrade --force foo configure.optflags="-Os -g" > Additional files are not saved alongside the port. You should probably > avoid depending on external files for the pre- and post-deactivate > phases and running the Portfile. Or doing anything with them in the shared parts of the Portfile... > We could argue that's a bug, but this has worked quite fell so far. As long as it doesn't make it impossible to do something that's absolutely necessary, it's not a bug but just as shortcoming ;) R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
