How can variant B imply variant A?

[Michael Dickens]

Hi Mojca - I assume I was included because the qt4-mac / gnuplot issue
you described (as forwarded below)?  If I understand what you wrote, I
really don't see that as an issue since it was a current version of
qt4-mac and an archived version of gnuplot.  I think the vast majority
of users will not be encountering this issue; it'll be just a handful
of developers and hackers, and they will have "asked for it" :)  I'm
not sure there's any reasonable way to guarantee that a current port is
compatible with an older, archived version of another port; just too
many possibilities of things that could go wrong there.  Or, maybe I
don't understand what the issue really is, or its importance? - MLD

On Aug 22, 2012, at 3:23 AM, Mojca Miklavec
<mojca.miklavec.lists at gmail.com> wrote:

  However I just noticed a "serious" problem in my current setup,
  probably related to what you mentioned above.
  I recently installed "qt4-mac +framework" and I just pulled an old
  gnuplot out of archive (sudo port activate gnuplot @...) which now
  crashes with
  dyld: Library not loaded: /opt/local/lib/libQtNetwork.4.dylib
   Referenced from: /opt/local/bin/gnuplot
   Reason: image not found
  Trace/BPT trap: 5
  The same file is now in
  '/opt/local/Library/Frameworks/QtNetwork.framework/QtNetwork'.
  (I would not necessarily attempt to fix this though. Hardly any sane
  person would try to mess with multiple installations/variants of Qt
  and there was no other bug report related to that so far. I only
  imagine it being a problem if a port depending on Qt is fetched from
  buildbot and the user decided to install "qt4-mac +framework"
  variant
  earlier. I'm not excluding the possibility that my setup is messed
  up
  though, and that it's only broken on my machine.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120822/03e4b6a5/attachment.html>