On 2018-03-15 12:33:08 -0400, Tom Lane wrote:
> Andres Freund <andres@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
