Shibboleth Developers

[Ian Young <>]

I've been talking this over with Scott, but neither of us have good
answers or any really deep investment in the question, so I've been
asked to take it to the wider development community.

Background: Fedora Core is a popular Linux distribution.  It's fairly
bleeding-edge, so it does show us what is coming later in more
Enterprisey Linux distros; knowing this means we can tweak the sources
when they break the compiler before an enterprise release ever shows up
the problem.  The downside is that it is pretty unstable.  It's the
anti-Debian, really: frequent new releases, and sometimes updates
between releases can destabilise your system because they just throw the
latest thing in rather than back-porting security fixes.

Scott has been building RPM packages for the C++ SP for Fedora Core 3, 4
and 5 on (and I have to stress this) an unofficial, unsupported basis.
I recently agreed to do the same for FC6.  All these packages are
available from the download site.

One of the packages we build is xerces-c, version 2.6.1.  What happened
the other day is that a helpful person added (retrospectively) a
xerces-c version 2.7 to the Fedora Extras repository for (at least) FC5
and FC6.  The way the automatic update rules work means that:

* this looks like a new version of our package

* so it tries to update it

* but we have other packages that depend on the particular library version

* so the update fails

* so *every* automatic update now fails on any machine that has our
Shibboleth RPMs installed

This is obviously undesirable, as it looks like Shibboleth has broken
the ability to get security patches on the affected system.

There are a number of things we could do to resolve this.  The ones I
can think of are:

1. Say "Hang spring-cleaning!" and go have a picnic, on the basis that
all this is unofficial and unsupported and Fedora is just too flakey to
keep up with.  I guess to be really consistent about that, maybe we'd
want to remove the existing Fedora Core RPMs from the download site and
get people to build their own from the SRPMs in future.  This would be
consistent with how we'd expect things to go for Shibboleth 2.0.

2. Build (and test) new packages for FC5 and FC6 that assume the
presence of xerces-c-2.7 in the system.  People whose systems are
currently broken could upgrade the dependent packages while upgrading to
xerces-c-2.7 and dig themselves out of the hole.

3. We could do what the openssl people have done, which is to move our
xerces-c sideways and call it something like xerces261-c.  If that
packaged was marked as obsoleting xerces-c 2.6.1 then people could
update that without updating the dependent packages, and it would still
be possible to install the xerces-c-2.7 if required for something else.

If you don't understand what I mean by option 3, a quick look at the
openssl packages I have on my (much upgraded over the years) FC5 system
might help:

        openssl-0.9.8a-5.4
                providing *.so.6

        openssl097a-0.9.7a-4.2.2
                providing *.so.4

        openssl096b-0.9.6b-21.42
                providing *.so.2

You need something to allow different shareable library versions to
co-exist when their ABI isn't maintained across versions, and this seems
to be what people in RPM land do in this case.  It's not pretty, but it
does seem to work.

If we were seriously trying to "support" Fedora Core on any official
basis, we'd have to do either option 2 or option 3.  As it is, Scott and
I don't even have any real idea as to whether anyone uses any of the
Fedora Core packages, so perhaps taking option 1 is something no-one
would even notice.

Enough exposition, I guess.  Anyone have any ideas about how we should
approach this?

        -- Ian