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

[Cantor, Scott]

On 3/16/14, 5:48 PM, "Russ Allbery" <rra at debian.org> wrote:

>libshibsp6 would depend on shibboleth-sp2-common.  libapache2-mod-shib2
>would depend on shibboleth-sp2-utils.  Every other package would retain
>its current contents and dependency structure.  (I know the authorizer and
>responder need to be split off somehow eventually into a FastCGI package,
>but I'll deal with that later.)

Was going to mention that, ok.

>Some things that I'm not sure about:
>
>* Should the *.so files stay in the Apache package, or move to something
>  else?  Does it make sense to put them in the -utils package along with
>  shibd?  Or do they need to go into some other package of their own?
>  (They can't go into the library package directly because they aren't
>  versioned; presumably the ABI doesn't change between library releases?

They're not linked to, they're plugin extension libraries that are
specific to the ABI of the surrounding libraries they're built against.
Nothing would ever link against them. They really belong with the library
package, or if not, then in one or more extension packages representing
the features they include.

The ODBC plugin is the only thing that requires ODBC, for example, same
for memcache.

>  Or if it does, I should move them to a directory versioned by ABI
>  version and then include them with the library package.)

These files don't really have an ABI themselves, any more than Apache
modules do, that's why I grouped them together.

>* Does it make sense to folks to have all the utilities including shibd
>  collected together in shibboleth-sp2-utils?  This would include
>  shib-metagen, resolvertest, mdquery, and shib-keygen along with shibd.
>  I kind of don't like having daemons in a -utils package, but I think
>  splitting things further just creates a ton of packages for no
>  particular purpose.

All of the utilities are fine together, but I can't really say for sure
what to do with shibd. Based on what you're saying, it probably really is
its own package if it can't be with the libraries, and the Apache package
should depend on it. It's very unlike those utilities, none of which are
in any way required to run all this.

-- Scott