Take the 2-minute tour ×

I maintain a couple of large packages that we use internally and starting with the next release I would like to split those into smaller packages. These packages are already installed in a number of machines via our custom apt repository and I am not sure what the upgrade path would be for those who already have this big packages installed.

To illustrate the issue:

packageX is the current big package installed in a number of machines

I would like to split it into:

  • packageX-foo
  • packageX-bar
  • packageX-baz

I guess the sensible thing to do would be to create a virtual package called packageX that encapsulates all of the new packages, does that sound about right?

How can I ensure that an apt-get update && apt-get upgrade wouldn't break things for users?


share|improve this question

2 Answers 2

Yes, making packageX a virtual package that depends on the others is the usual way to handle this.

That way everyone who has packageX installed now will have all packageX-* packages after the upgrade. Plus it makes it easy to install all of packageX for those who want that.

Depending on your software it may be worth thinking about creating additional virtual packages which depend on often used subsets of packageX-*` to simplify the installation of those subsets.

share|improve this answer
  1. packageX should Depends: packageX-foo, packageX-bar, packageX-baz. This ensures that upgrades automatically pick up each individual new package.
  2. Each packageX-component should: Breaks: packageX (<< V) and also Replaces: packageX (<< V) where V is the new version. This ensures that the package manager knows that the files in the new component packages conflict with the files in the old monolithic package.
share|improve this answer

Your Answer


