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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
