On 2018-03-15 12:33:08 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2018-03-15 17:19:23 +0100, Catalin Iacob wrote: > >> Indeed. It might be a bit awkward for packagers to depend on something > >> from Software Collections, for example because they come as separate > >> trees in /opt that are by default not in your path or dynamic loader > >> path - one needs to run everything via a scl wrapper or source the > >> /opt/rh/llvm-toolset-7/enable file to get the appropriate PATH and > >> LD_LIBRARY_PATH settings, But it seems doable. > > > It'd be just for clang, and they're not *forced* to do it, it's an > > optional dependency. So I think I'm ok with that. > > The "software collections" stuff was still in its infancy when I left > Red Hat, so things might've changed, but I'm pretty sure at the time > it was verboten for any mainstream package to depend on an SCL one.
But we won't get PG 11 into RHEL7.x either way, no? > But they very probably wouldn't want postgresql depending on a > compiler package even if the dependency was mainstream, so I rather > doubt that you'll ever see an --enable-jit PG build out of there, > making this most likely moot as far as the official RH package goes. > I don't know what Devrim's opinion might be about PGDG. It'd be a build not runtime dependency, doesn't that change things? Greetings, Andres Freund
