= Package updates in yum = == Package update, simple == A new version is released upstream, or just within the repo. with local patch(es): * pkgA-1.2.3-4 is installed * pkgA-2.3.4-5 is available In this case pkgA just updating the version in the package and rebuild, and pkgA will be updated to the new version. This is what happens 99% of the time. == Package rename == A new version is released, but it changes the name: * pkgA-1.2.3-4 is installed * pkgB-2.3.4-5 is available The usual thing to do here is to have: {{{ # pkgB-2.3.4-5 Obsoletes: pkgA <= 1.2.3-4 }}} Now pkgA will be updated to pkgB. However note that pkgA-1.2.3-4 can be installed via. rpm, after pkgB is installed. You may want to have something like: {{{ # pkgB-2.3.4-5 Conflicts: pkgA <= 1.2.3-4 }}} ...to stop that. For compatibility you may also want to do: {{{ # pkgB-2.3.4-5 Provides: pkgA }}} ...as now packages which "Requires: pkgA" will continue to work. == Package split == In general you have N things inside one package and move to a point where you have N packages all providing one thing, you cannot easily decide for the user which of the N things they wanted originally. So the general case let's the user decide: === General case === A package splits into two: * pkgA-1.2.3-4 is installed * pkgA-2.3.4-5 is available * pkgA-foo-2.3.4-5 is available This is a similar problem to the rename, except that we are renaming some of pkgA to one place and some to another (the same place): {{{ # pkgA-foo-2.3.4-5 Obsoletes: pkgA <= 1.2.3-4 # pkgA-2.3.4-5 Obsoletes: pkgA <= 1.2.3-4 }}} Now on update pkgA will be updated and pkgA-foo installed. If you don't have the Obsolete in pkgA then it will work as a rename, which is probably not what you want. However if the user does "install pkgA-foo" or "install pkgA-2.3.4" they will end up with just pkgA-foo or pkgA, respectively. === Package split in two, Application and noarch data === A package splits it's (large) data into a noarch sub-package: * pkgA-1.2.3-4 is installed * pkgA-2.3.4-5 is available * pkgA-data-2.3.4-5 is available This is somewhat different in that you have a very high expectation that a user will want '''both''' installed afterwards, and never '''just''' pkgA or pkgA-data: {{{ # pkgA-2.3.4-5 Requires: pkgA-data = 2.3.4-5 # pkgA-data-2.3.4-5 Requires: pkgA = 2.3.4-5 }}} Now pkgA and pkgA-data will always '''both''' be installed. === Package split in two, Application and new libraries === A package does a new release which adds libraries other packages can use: * pkgA-1.2.3-4 is installed * pkgA-2.3.4-5 is available * pkgA-libs-2.3.4-5 is available This is somewhat different in that you have a very high expectation that a user will want '''both''' installed afterwards, and never '''just''' pkgA-libs (because -libs wasn't available before): {{{ # pkgA-2.3.4-5 Requires: pkgA-libs = 2.3.4-5 }}} Now pkgA and pkgA-libs will be installed on upgrade, and some pkgB can then depend on just pkgA-libs and people who don't have pkgA installed will not get it. To repeat: If the old pkgA provided libs and you are just splitting them from one package to two, it is not obvious that the user doesn't want '''just''' pkgA-libs. == Package merge == A package merges a sub-package into the main package: * pkgA-1.2.3-4 is installed * pkgA-foo-1.2.3-4 is installed * pkgA-2.3.4-5 is available This is basically the same problem as a rename, so the solution is the same: {{{ # pkgA-2.3.4-5 Obsoletes: pkgA-foo <= 1.2.3-4 }}} Now pkgA will be updated and automatically remove the old pkgA-foo-1.2.3-4. == Package update, requires newer interface == A package depends on something else, and older versions will fail. * pkgA-1.2.3-4 is installed * pkgB-3.4.5-6 is available * pkgA-2.3.4-5 is available * pkgB-4.5.6-7 is available The obvious solution here is: {{{ # pkgA-2.3.4-5 Requires: pkgB >= 3.4.5-6 }}} ...which will bring the new version of pkgB along if pkgA is updated. == Package update, fails with older interface == A package _doesn't_ depend on something else, but older versions will fail. * pkgA-1.2.3-4 is installed * pkgB-3.4.5-6 is available * pkgA-2.3.4-5 is available * pkgB-4.5.6-7 is available The obvious solution here is is to do the require, but in fact you want to do: {{{ # pkgA-2.3.4-5 Conflict: pkgB < 3.4.5-6 }}} ...this will update pkgB, if it's already installed, but do nothing otherwise.