Shibboleth Developers

["Scott Cantor" <>]

Bernd Oberknapp wrote on 2009-10-23:
>> All of them would conflict, right? Not just those two...
> 
> Surprisingly, no.

Hmm, I guess that's a clue, I'll have to dig into it and try it. Is there a
link where I could get to the packages you had installed and upgraded from?

> shibboleth, opensaml and xml-security-c are recognized as updates for
> the existing RPM packages created from SRPMs.

Right, but opensaml and xml-security-c are also packaged with the SUSE
naming conventions (libsaml2 or whatever it is, etc.), aren't they?

> The only problem is that
> libxmltooling and liblog4shib aren't recognized as updates for
> xmltooling and log4shib.

That part I understand, but it should be the same for the others.

> Installing liblog4shib in parallel with log4shib also works fine, and
> reoving log4shib doesn't break liblog4shib. Same for libxmltooling and
> xmltooling and the other packages.

Right, that's because they're separate sonames and the packages don't have
any conflicting files.

> Therefore my conclusion that if libxmltooling and liblog4shib would
> be recognized as updates for xmltooling and log4shib an automatic update
> of all packages would be possible.

I'll try to fix them, I just don't know what would be different about them.

> The update from 2.2 and 2.1 also preserves an existing /etc/init.d/shibd
> as /etc/init.d/shibd.rpmorig and a changed /etc/apache2/conf.d/shib.conf
> as shib.conf.rpmsave
> 
> If this is different from Red Hat/CentOS, maybe there's some yast/zypper
> magic involved?

I may have misunderstood, and I probably assumed that they didn't do the
right thing. Upgrades do the new package install first, so if the files are
marked as config(replace) in the new package, that would be the step that
preserves the old ones, I suppose.

What I was thinking of is that if you do an rpm -e on the old package, that
will probably end up removing those files without saving them because they
aren't known to be config files until later versions.

Anyway, never hurts to document it and tell people to be cautious. If you're
saying you weren't expecting it to move your shib.conf out of the way,
that's by design, for the reasons I stated in the wiki.

Thanks,
-- Scott