2

I have an RPM whose software recently had its database schema completely redesigned. The current version (We'll call it B.0) is incompatible with older versions of the database schema.

Fortunately it's still in beta, and since it's not officially released I'd like to avoid writing any database migration scripts unless (and until) it actually becomes necessary to do so.

An upgrade will fail, because the (new) database schema creation happens in a scriptlet that is never run during an Upgrade, which puts the application in a bad state. If A.x is installed, I want them to erase and re-install.

I have found RPM's "Conflicts" tag, which does seem to do the job, but the error message is misleading "file ____ conflicts with file from package A.x" and someone with enough savvy might try to Upgrade and replace conflicts, which isn't useful as the required scriptlets to create the database still won't be run.

Is it possible to print a more descriptive error message when this Conflict occurs? Is there a "right way to do this" alternative?

InfernalRapture
  • 121
  • 5
  • You could check for an update/upgrade in the pre-install script, and then abort if you don't support it. Users won't consider that to be nice, however. – U. Windl Jun 13 '22 at 12:26

1 Answers1

2

If your package cannot be upgraded, you should consider renaming the package. For example, if the third release of your software was a rewrite, you might end up with foo3-3.0.0-1.x86_64 which obsoletes foo <= 3.0.0.

This is appropriate only when an upgrade path is not technically possible.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

Also, since you mention it is a beta, you may want to look at their Versioning Guidelines to keep it numerically sortable. (You will want the non-beta release to replace the beta.)

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/

Aaron Copley
  • 12,345
  • 5
  • 46
  • 67