Get Gentoo!
Development Guide
  1. Master index
  2. Ebuild maintenance

Removing ebuilds and packages

Removing ebuilds

When removing an ebuild make sure that no dependencies in Portage are broken due to the removal — additionally, your git commit message should explain clearly why the ebuild is being removed from the git repository.

If you need to remove ebuilds, make sure you do not accidentally remove the newest/only stable ebuild for any architecture. If you would like to get a newer version marked stable, then please file a bug or ask on IRC.

You should also not cause an unnecessary downgrade for any ~arch when removing ebuilds — instead, it is best to get the newest version marked ~arch first and then remove redundant versions of the ebuild.

Removing a package

When removing packages follow these steps:

  1. Make sure that no dependencies in the Gentoo repository are broken due to the removal
  2. Send last rites to gentoo-dev-announce and gentoo-dev
  3. Mask the package
  4. Wait 30 days (or more)
  5. Remove from the git tree unless the reason for removal has been fixed
  6. Remove any references to the package from other ebuilds, e.g., use-conditional dependencies. Blockers are the only exception to this.
  7. Remove package.mask and any package.use.mask entries
  8. Remove the <pkg> tags referencing this package in the metadata.xml files of other packages.
  9. Close open bugs as PKGREMOVED

Here is a list of commands that will delete dev-util/pmk from the tree: 

# cd dev-qt
# git rm -rf qtphonon
# git commit --signoff --gpg-sign

An example commit message is shown below: 

commit b97eb6d43f45dfd5b739638928db22d3f3392685
Author: Michael Palimaka <[email protected]>
Date:   Tue Oct 3 21:43:03 2017 +1100

  dev-qt/qtphonon: remove last rited package

  Closes: https://bugs.gentoo.org/629144

Removing a virtual package

Virtual packages are generally removed when they have no more than one provider left. The removal is preceded by updating the remaining ebuilds not to use the virtual. Since virtuals do not install any files, there is little value in proactively forcing them to be uninstalled from user systems or unnecessarily informing the user about the fact. Therefore, an alternative removal process is recommended.

In order to remove a virtual package, follow the following procedure:

  1. If the virtual is being removed along with any of its providers, include the virtual in the last-rites mail. However, please do not include it in the package.mask entry as users do not need to be forced to proactively unmerge it. Instead, add it to package.deprecated to warn developers not to depend on it. Wait the time appropriate for the last rites.
  2. Update all ebuilds not to reference the virtual, following normal Ebuild revisions policy
  3. Remove the package directly
  4. Perform the post-removal cleanup, as with regular packages