Shibboleth Developers

["Scott Cantor" <>]

> Our preference would be for option 3. But then again we could just put
> xerces-c in the yum excludes list and forget about that issue until
> there are major dependency issues. At the moment only the xerces-c-devel
> and xerces-c-samples packages have any dependencies on xerces-c

Well, my sense is that once-burned, twice-shy on this and since we're not
"officially" supplying packages to these distros, we probably need to start
being defensive about the dependencies and follow the only convention that
seems to be possible, putting the version in the package name.

That seems silly, but it appears to be the only way to prevent this from
happening unpredictably. I thought that library packages were somehow immune
from this if the SOs were versioned but obviously not. For all we know,
somebody could slip an opensaml RPM into extras, so even that's not
guaranteed.

Once a package works its way into release or updates, then it's reasonable
to rebuild on top of it, but not until then I guess.

So while I'm still inclined to stop putting out RPMs for Fedora, because I
just think it changes far too much, if we don't, I think we have to reissue
a new set on top of renamed dependencies. I think those are the choices.

As it is, I would still like to pull the now-unsupported Fedora versions for
sure, either way.

-- Scott