Update FAQ entry on python dependencies

[warren@…]

When looking into a failure to build Mercurial, I found that python requires an enormous amount of dependencies. I found some of tickets related to this:

​http://trac.macports.org/ticket/18957
​http://trac.macports.org/ticket/19416
​http://trac.macports.org/ticket/19907

All of these refer to a FAQ entry:

​http://trac.macports.org/wiki/FAQ#pydeps

I think that the workaround suggested in 19907 (install tk variant quartz as step one) should be documented in the FAQ. tk is the source of most of the irrelevant dependencies, and using the quartz variant was the solution to my problem.

Suggested additional paragraph:

The python26 package depends on tk, which itself has many dependencies, due to its dependence on X libraries. If you do not require the X version of tk, or do not care, you can install the quartz variant, which has fewer dependencies.

[blb@…]

Note that the entirety of xorg-based dependencies for tk number at 17, but half are proto ports (just install headers). If it's disk space you're worried about, all of those take about 12M of space (most being xorg-libX11), which is about 1/5 that of just python26. For build times, those proto ones are extremely quick and the rest are quite fast as well (again, especially when compared with python26).

Aside from those bits, what other issues do you have with tk bringing in these dependencies? I ask because I've heard once or twice that tk+quartz may have problems with python's tkinter.

[warren@…]

My issue was that one of the X-based dependencies failed to build. I plugged the error into google, and found ​http://trac.macports.org/ticket/18835. Obviously, it's environment-specific, as otherwise the maintainer would be getting the same failure, or the advice given would have worked (it didn't).

In an ideal world, I'd care about whether some X-based 4th-degree dependency didn't build, file a new ticket, and work with the maintainer towards a resolution. But I don't care. I found a solution that eliminated 17 sources of failure, allowed me to install the software I did care about, surmised that it might be useful to others, and filed this ticket hoping that you shared my view.

If you don't, that's fine. Close wontfix; no hard feelings!

[blb@…]

If the error you saw was also

Requested 'xproto >= 7.0.13' but version of Xproto is 7.0.11

then the solution is to upgrade your xorg-xproto port (which is currently 7.0.15, definitely passing the >= 7.0.13 test). Also, if that's the case, that's more an issue with the fact that MacPorts will upgrade an out of date dependency when you use 'port upgrade' but will not if you use 'port install'.

[blb@…]

The issue of 'port install' not upgrading dependencies should be taken care of by jmr in r54893.