<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 5:43 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">On Jan 27, 2016 09:00, "David Cournapeau" <<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>> wrote:<br>
><br>
[...]<span class=""><br>
> The main argument against using centos 5 is GUI-related components, as the old fontconfig/glib (the GTK one, not Gnu libc) are a problem. But those are a tiny minority of what people do with python nowadays, and they require a lot of work to get right.</span></p>
<p dir="ltr">This is the part that intrigued me :-). Can you elaborate at all on what kind of problems you've encountered with fontconfig and glib?</p>
<p dir="ltr">(Well, I can guess at one piece of excitement maybe: that glib is not really vendorable because a process can have only one main loop, and that lives in glib these days for both gtk and Qt, so any packages doing any GUI stuff are required to agree to use the same glib version.)</p></blockquote><div><br></div><div>So vendoring glib is possible (we actually do it ATM, though we may revert that). The problem is that now when you load say PyQt w/ Qt linked against your vendored glib, you get into issues if that glib is higher than the glib used in the system (that happens through pango IIRC). So if you want to stay compatible, you need to build an old glib, which is what you were trying to avoid in the first place. There is no good solution, really<br><br></div><div>David<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
<p dir="ltr">-n</p>
</font></span></blockquote></div><br></div></div>