preventing known-damaging third-party to fedora/epel package upgrade?

[Paul Wouters]

Hi,

One of the packages I maintain is shipped with a version of 1.4.x.
Upstream has a 1.3.x branch. The 1.3 branch is considered stable by
upstream, but my experience was that 1.4.x was actually more stable.
Additionally, migration from 1.3 to 1.4 was tedious and involved
manually changing sqlite/mysql tables. Therefore neither Fedora nor EPEL
ever shipped 1.3.x, and we started out with 1.4.x.

Unfortunately, the spec file from upstream did not use
%config(noreplace). Someone enabled epel and ran "yum update" and the
EPEL package was seen as an upgrade, and the noreplae bug in their
package caused our package to blow away their configuration.

I would like to prevent this from happening. But since this only happens
when  upgrading from a third-party 1.3 (which we don't ship) to a 1.4,
even if I used triggers to work around the config file issue, the users
would end up with a broken database setup anyway. I could address that
with an auto-migration script, but then any accidental upgrade would be
even harder for those people who wanted to remain on 1.3. to downgrade back.

So perhaps the best way would be to never allow the upgrade from 1.3.x
to 1.4.x. Is there any kind of support for this? Looking at the
triggers, and the fact that the bad packages are already installed on
those systems, I don't think any of the triggers, even %triggerin,  will
be usable for this?



Paul