RPM upgrades and SSPCPP-345

[Cantor, Scott E.]

Most are aware of the complaints surrounding the use of config instead of
config(noreplace) on the shib.conf Apache configuration file, and at the
very least the totally incorrect comments in the file misleading people to
edit it, and the problems with the content that's already in it.

I'm working on new packaging starting with the possibility of switching it
to (noreplace), with the fallback being splitting into two files, one
that's replace and one that isn't.

The problem is that SUSE packaging guidelines, which the Build Service
enforces unilaterally for SUSE platforms, disallow the use of %post
scripts that modify pre-existing files. Specifically, if I use a scriptlet
to "fix up" older shib.conf files to make sure things work properly after
an upgrade, the package won't build.

In order to switch the file to (noreplace), I have to do two things:

- do something about the version-specific Alias commands pointing to
default CSS and logo
- make sure I know how to handle a breaking upgrade if it requires
Apache-level changes

The latter I think I can address, if it happens, by renaming the file and
packaging a no-op shib.conf marked as (replace) in a future breaking
upgrade. It's hopefully unlikely enough that if it happens, there will be
a good reason.

The former I'm stuck with. I can move the logo.jpg and main.css files to
/usr/share/shibboleth so that they're not docfiles (which they aren't) and
aren't version specific. They're read only, so there's no problem putting
them there.

But I can't do anything about the legacy config Aliases if I can't change
the old file. So I see it as two options:

- live with it, break the Aliases once, and document the issue
- abandon the single config goal and split the config

Ordinarily I wouldn't consider the first option, but people seem to be
violently opposed to /etc/httpd/conf.d containing (replace) files, and the
Aliases themselves are really just for the default error pages using the
Shibboleth logo, which weren't meant to be used in production anyway. I
could probably just remove them outright and I still might, but I'm left
with the same problem, so it doesn't change the question.

-- Scott