Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

[Russ Allbery]

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

> Yeah, I get it, and yes, they are linked directly to specific ABIs. If
> the ABI changes, that's when the SONAME changes on libshibsp or the
> others.

> The intent is that they're part of Shibboleth proper, rather than part
> of the library package, in the sense that two versions of libshibsp
> should work side by side but two versions of the SP as a whole don't.

> The location was derived from the Red Hat convention for Apache modules,
> which I'm not defending, just explaining. The file system standards
> don't really address plugins that I'm aware of.

Yeah, they don't.  What we've generally done in Debian is create
per-SONAME directories (using some naming convention that works for that)
and put the plugins in there.

I'll file a bug about this for the long term.

> Yeah it is, so I suppose there's probably a way to get that into the
> build such that each updated build would have a version-specific
> location to auto-resolve plugins from. I don't test that all very much,
> similarly to how building Kerberos in non-default ways makes for an
> interesting experience.

> On Red Hat, the files are part of the main "binary" package that doesn't
> support side-by-side installation.

> Would it be possible to have a shibboleth-sp2-<something> package for
> shibd and those plugins that would be one version at a time?

This is what I did for now.  I created a libshibsp-plugins package and a
shibboleth-sp2-utils package and made the dependencies from
libapache2-mod-shib2 and from -utils to -plugins strict (to require
exactly the same version).

I think that will do for now, but it does have some problems.  For
example, if another package wants to use the library and the plugins, it
would:

    Depends: libshibsp6, libshibsp-plugins

Then, when there's a new ABI, it would be rebuilt and have:

    Depends: libshibsp7, libshibsp-plugins

The problem is that the libshibsp-plugins from the earlier version of
Shibboleth still satisfies that relationship, so it could have its
dependencies satisfied but no plugins.  In order to correct that, every
package that depends on the plugins needs to be strict about the version,
which is hard to do across packages.  And that also means that only one
version of the library can be fully usable at a time in practice, since
everything will force upgrading the plugins, and then the old version
won't work because it won't have plugins.

However, for the time being, the Apache module and shibd are probably the
only real users, so in practice this will generally work for the time
being.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>