Shibboleth2 packaging

[Scott Cantor]

> I'm not sure that it makes sense to provide *only* 2.0 in Debian lenny (if
> we can even get 2.0 into the archive by the freeze), when a lot of sites
> are still running 1.3, although that does mean 1.3 would be around for
> possibly longer than it should be.  But maybe I'm too conservative.

A lot of sites will run 1.3 until they're forced to change, including past
the point where it goes unsupported. Sometimes its best to just force people
to do what's necessary if they choose to rely on packages.

That said, my point is more about whether one can install BOTH. Since the
versions are sequential, if I could choose to install 1.3 or install/upgrade
to 2.0, that seems reasonable as well. But I realize that having packages
inside a distribution is another matter.

With the RPMS, since they are not part of Red Hat, it's a trivial matter to
maintain both and people can pick what to install. e.g. when RH6 comes out,
I'll still be supporting 1.3, so there will be RPMs for both 1.3 and 2.0.

> We can package both at the same time and just have them conflict with each
> other; that's not horribly uncommon in Debian.  It's not really ideal, but
> it has its advantages for sites that aren't ready to jump to 2.0 yet.  I'm
> not really sure what to think there.

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.

> Partly that's because I don't have practical experience with the upgrade
> yet, which I'll get this summer, so maybe it's not as big of a deal as I
> thought.

The new SP installs on top of the old one such that it does NOT destroy any
old config files, even while not using them. The new SP is not compatible
with the old files, but it can be configured easily to behave such that no
applications should have to change when that's required.

> Huh.  I could have sworn that I tested this explicitly and everything
> worked fine without the schemas involved, but clearly I missed something.

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.

With 2.0, this has changed. I stopped duplicating files, and I merge
catalogs of schemas across the xmltooling/openssml/shibboleth trees, so they
are required now.

> BTW, there are currently two packages for the Shibboleth SP libraries for
> 1.3 since libshib and libshib-target had different SONAMEs and I wasn't
> sure if that would indicate that they might change versions independently.

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.

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.

-- Scott