On Tue, 2017-01-31 at 16:23 -0500, Colin Walters wrote:
David is on an epic quest. It's like he's Frodo Baggins, trying to battle many trials and adversaries (libmozjs, upstreams of e.g. libcurl) to dump the ring (pacrunner) in the volcano[1].
What can I say? I like to tilt at windmills :)
So then if I understand things, we'd need to teach ostree to talk to NM. Theoretically, libproxy could learn to talk to NM/connman/whatever itself too. Or hm, no, maybe I misunderstand, it looks like the NM patches push to PACRunner, so we'd talk DBus to that? Wait, I looked more, I see a C shared library that talks to the pacrunner daemon. So yeah, we'd need to patch OSTree to use that or speak DBus directly (some preference for the latter).
Right. NetworkManager now pushes the proxy information to PacRunner. Applications should simply ask PacRunner "what proxy do I use for <this> URL?". There is a patch (long-outstanding) to the "real" libproxy which adds "just ask PacRunner" support: https://github.com/libproxy/libproxy/pull/35 The C shared library you're looking at is probably PacRunner's own reimplementation of libproxy.so.1 which does *nothing* but ask PacRunner, and leaves behind all the other nonsense that the real upstream libproxy has become. Once the NetworkManager/PacRunner bits land in distributions and PacRunner is consistently returning appropriate answers to the question it gets asked, *then* my next windmill to tilt at is getting applications to use it by default. I'll be proposing Fedora Packaging Guidelines to that effect. For some apps that might be through an existing libproxy support; for others it might be be using DBus to talk to PacRunner directly. As you imply, that's a matter of preference...
Attachment:
smime.p7s
Description: S/MIME cryptographic signature