How can variant B imply variant A?

[Michael Dickens]

Hmm … does (I think it's called) rev-update do its thing after
installing from archive?  It's the post-install "Updating database of
binaries" and "Scanning binaries for linking errors" check.  If it
does, then it should catch the linking error between qt4-mac +framework
and gnuplot, though I'm not sure what it can do if an older version of
gnuplot was installed from archive that is not compatible with the
current qt4-mac install.  The archival capabilities can only go so far
in terms of variants.
I have thought about qt4-mac's dual library / framework build, since it
causes these sorts of issues.  I'm wondering if trying to install
qt4-mac as dual framework / library would work: install as framework
internally (to the Qt build), and then link from the frameworks into
${prefix}/include/Qt* and ${prefix}/lib/libQt*.  The former is already
done, and seems to work well.  Doing the latter is a relatively simple
extension of the former.  If both libraries and frameworks were
installed, always, then dependent ports could choose which one to link
to and would, after the change, always be backwards compatible with
older versions.  Yes, this might make sense to look into.
Thoughts on the above? - MLD
On Aug 22, 2012, at 9:46 AM, Mojca Miklavec
<mojca.miklavec.lists at gmail.com> wrote:

  On Wed, Aug 22, 2012 at 3:29 PM, Michael Dickens  wrote:

  Hi Mojca - I assume I was included because the qt4-mac / gnuplot
  issue you
  described (as forwarded below)?

  Exactly.

  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.

  I totally agree with that point of view. (I was just a bit less
  explicit.)

  Or, maybe I don't understand what the issue really is, or its
  importance? - MLD

  I wrote that for two reasons (apart from being bitten by it in the
  morning). The first reason is that user may legally do the
  following:
  - install "qt4-mac +framework"
  - install another port with default dependency on qt4-mac which was
  built with buildbot and depends on
  /opt/local/lib/libQt<whatever>.dylib
  This is not a problem with gnuplot since gnuplot has to be built
  from
  source. But it might be a problem for other packages. I'm not sure
  how
  serious problem that is though. I don't expect many people would
  really want to use "+framework" flag anyway. I used it out of pure
  curiosity, and even then it's painful. With default setting
  upgrading
  to new revision takes a fraction of a minute. With +framework
  upgrade
  takes hours and hours and hours. I would not worry about this unless
  bug reports start flying in.
  The second reason why I wrote it was the response to this thought:

  This is just a bad idea: your package will install differently based
  on what's available, and not even consistently (e.g. archives).

  (I was thinking of choosing the port variant based on whether
  wxWidgets or wxWidgets-devel is already present. This would actually
  not break archives. But currently "qt4-mac +framework" does.)
  It's not really a serious issue, however it might be worth keeping
  it in mind.
  Mojca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120822/96fc7439/attachment.html>