breakage from r99712

[Jack Howarth]

On Sat, Nov 17, 2012 at 12:00:42PM -0500, Jeremy Huddleston Sequoia wrote:
> 
> On Nov 17, 2012, at 11:48 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> 
> > Jeremy,
> >    I would think, as the X11 maintainer, you would show more sensitivity on this issue
> > rather than just to declare software that uses blt such as pymol as being DOA.
> 
> You are conflating two separate issues:
>   1) tcl now enables CF support by default (you can still disable it)
>   2) tk is now quartz by default (you can still disable it to use x11)
> 
> Re 1) Yes, CF is not fork()-proof, but neither is most of libSystem.  As soon as you touch anything beyond POSIX, all bets are off.
> 
> Re 2) I actually think that the *average* user would probably prefer the native client over X11.  That being said, I think there should maybe be a +x11 variant in tk to assist with this.
> 
> > The
> > situation with thread support on tcl/tk is known to be suboptimal..
> > 
> > http://wiki.tcl.tk/1339
> > 
> > Vendors like Redhat solved this as described in...
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=478961
> > 
> > by providing both a non-threaded and threaded tcl package. This is exactly the 
> > solution we had prior to r99712 where the default package didn't support threads or
> > CoreFoundation (which drags in threads) but both were available in the threads and
> > corefoundation variants. The change in r99712 makes little sense as it leaves the
> > now redundant corefoundation variant in place. It should have at the very least
> > converted the corefoundation variant into a no-corefoundation variant so as to
> > not leave blt users (and other such packages that use fork() in tha manner)
> > stranded.
> 
> AIUI, the only things really changing here are what variants are enabled by default.  You can still change variants if you don't like the new defaults.  Users with the old defaults will continue to update with their old choices (unless enforcing variants).

Jeremy,
   Am I reading this wrong...

http://trac.macports.org/ticket/126

It seems to imply that MacPorts doesn't allow a Portfile to enforce a variant in depends_lib?
         Jack
ps This seems like a horrible situation and we have just shifted the pain and suffering around.
The current situation allows packages like pymol to become randomly broken and will totally
confound end-users.

> 
> So as I said, if it's broken now, it was already broken before ... just less visibly.  I'd rather put energy into fixing the issue than hiding it again.
> 
> --Jeremy