log4shib and pkg-config

Ferenc Wágner wferi at niif.hu
Fri Jul 29 14:03:05 UTC 2016


"Cantor, Scott" <cantor.2 at osu.edu> writes:

>> I published my current patch queue for xmltooling at
>> https://anonscm.debian.org/cgit/pkg-
>> shibboleth/xmltooling.git/log/?h=patch-queue/debian/experimental
>> (an ephemeral branch just providing a preview).
>
> If you get something final done, please attach it in Jira or create a
> new issue if there's nothing there already.

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.

>> I tried to use mainstream solutions and hope that any problems arising
>> on your supported platforms (for example PKG_INSTALLDIR macro being
>> unavailable in pkg-config older than 0.27) will be easily fixable.
>
> Well, easily fixable basically means "this gets used if it can be, but
> there has to be fallback to what was there before".

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

> One of the reasons for not doing these changes is that it just adds
> another layer to what's there but nothing can ever get removed.

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 -- I think a few
specfile conditionals would be reasonable for the very old platforms
requiring such treatment.  In return the manual presence checks should
be removed, otherwise the gains (simpler configure.ac, precise linking,
correct pkg-config files for Shibboleth) become questionable.

> Sorry to say, but as long as Solaris support is required, almost
> nothing can be the "only" solution, because there is no way to count
> on anything there due to the variability.

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.

>> I killed backwards compatibility in this test run, but that mainly
>> matters for xml-security-c, because xmltooling, opensaml2 and
>> shibboleth-sp2 are often released in lockstep and log4shib already
>> provides a usable pkg-config file.  A distribution can make a
>> coordinated transition, but you as upstream are in a different position.
>> How do you think this could work out?
>
> It only works if it works across every platform and version. There is
> no way to "transition" to anything, other than maybe years down the
> road. If this is removing the existing tests, I would probably not
> take it as a patch, because it would be a large amount of work for me
> to add this myself but not lose the existing tests.

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.
-- 
Feri



More information about the Pkg-shibboleth-devel mailing list