log4shib and pkg-config

[Cantor, Scott]

On 7/29/16 10:03 AM, Ferenc Wágner wrote:
> It is a "final" first iteration.  It works well for me across the
> Shibboleth stack.  I thought it's easier to talk about and review as
> separate commits, but I can squash everything into a single patch and
> attach that in Jira if you prefer that.

If you have the commits archived on Debian side and could include a link
to them, I could review the individually that way, but I would prefer
just a comprehensive patch I think.

> PKG_INSTALLDIR can be yanked out with no loss of previous functionality,
> as it wasn't configurable at all.

I meant the original tests for presence. I'm sure this is cleaner and
simpler to remove, but it's the old stuff that would be a problem I think.

> My changes depend on zlib, log4cpp, Xerces, libsystemd-daemon, openssl,
> nss and libcurl providing usable pkg-config files on all supported
> systems.  If some of them do not cooperate, pkg-config can be overridden
> on the configure command line by specifying variables like xxx_LIBS, or
> shipping stub pkg-config files for some dependencies

That *might* work, depending on how prevalent the issues are. Can you
elaborate on the command line approach or point me at docs for that?

I guess I ultimately don't care *that* much about how easy it is for a
source build if it turns out to be more of an edge case problem. It
really just depends on how many platforms these pkg-config files are
available.

> Pkg-config is available on Solaris.  Does it not work on the Solaris
> platforms supported by you?  That would pretty much be a deal breaker.

Everything is available on Solaris, but nothing can be assumed on
Solaris. Every Solaris environment is different. So the problem is that
you need the least common denominator for everything.

I don't do any non-testing builds there, all the builds are done by
people deploying the SP. So anything that makes the build harder is bad.

I don't think I would care that much about people having to manually
specify the locations, but I think figuring out the right flags to set
would be incredibly hard and you have to bear in mind that Solaris flags
are critical. Every little detail has to be right or the whole thing
blows up because of threading compatibility or things like that.

> I left in the functionality/feature tests, removing the presence/version
> checks only, which should be replaced by pkg-config.  Those could have
> also been kept as a fallback, but that subtracts from the usefulness of
> the whole idea, as you point out above.

Right, that's my problem with it. All I can really do is try it, and
that's going to be very time consuming, so if you're looking for a
general answer it's that I'd eventually look at this, but it may be a
long, long time down the road.

-- Scott