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.