Shibboleth2 packaging

Russ Allbery rra at debian.org
Fri May 9 02:09:23 UTC 2008


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

> That may be what I'm suggesting, without using the proper language. But
> the SPs SHOULD conflict. They simply can't run at the same time, that
> would have been a ton of extra work that I was not willing to do.

Ah, okay.  I feel better now; we're more on the same page than I thought.
Yeah, I don't think we should go to any effort to make them co-installable
given that, but it may be good to hang on to separate, conflicting
packages for both versions for one release cycle, particularly since it's
so late for lenny.

That means that the libapache2-mod-shib and libapache2-mod-shib2 packages
would conflict, as would the opensaml-schemas and opensaml2-schemas
packages, and they'd all use the standard paths.  We'd probably start by
packaging the Shibboleth 2.0 stuff as priority: extra and then switch it
to optional when we're pretty sure the packages are stable (although
really there's almost no difference between optional and extra in
practice, so that doesn't really matter).

> So, thinking back, the reason is that the SP package included copies. If
> you look, you'll see overlaps. So, you're right, for 1.3, the opensaml
> schemas aren't needed, I had forgotten that. Sorry for the confusion.

Oh, okay.  Good, I wasn't nuts.  :)

I'll revert the change to make it a dependency then, but for opensaml2,
we'll make that a dependency.

> The versions are definitely not linked or joined with the package
> version.  But I have no plans to ever package them separately and they
> would never change *absent* a package version change, so I don't know
> that it's necessary to package them separately.

Basically, the only reason to package them separately is if libshib might
change SONAMEs when libshib-target didn't, or vice versa.  If whenever one
of them changes, the other one is *guaranteed* to change, then they can go
into a single library package.  Otherwise, it's better to split them since
then dependencies will always be right.

> The -lite thing is different, as that's the exact same source code built
> and linked with a different #define set that omits pieces of code. Even
> if by some chance I changed only something that was compiled into the
> full version, I wouldn't take the time to notice.

That's an excellent example of where we should just put both in the same
library package, indeed.

Thank you very much for the information!

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



More information about the Pkg-shibboleth-devel mailing list