Removing Ebuilds and Packages
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
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:
- Make sure that no dependencies in the Gentoo repository are broken due to the removal
- Send last rites to gentoo-dev-announce and gentoo-dev
- Mask the package
- Wait 30 days (or more)
- Remove from the git tree unless the reason for removal has been fixed
- Remove any references to the package from other ebuilds, e.g., use-conditional dependencies. Blockers are the only exception to this.
- Remove package.mask and any package.use.mask entries
<pkg>tags referencing this package in the metadata.xml files of other packages.
- Close open bugs as WONTFIX
Here is a list of commands that will delete
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 <firstname.lastname@example.org> 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:
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.maskentry as users do not need to be forced to proactively unmerge it. Instead, add it to
package.deprecatedto warn developers not to depend on it. Wait the time appropriate for the last rites.
- Update all ebuilds not to reference the virtual, following normal Ebuild Revisions policy
- Remove the package directly
- Perform the post-removal cleanup, as with regular packages