Revision bump
Revision bumping, also known as revbumping, is the act of updating an ebuild to a new revision. This article describes the procedure to be followed.
When is a revbump needed?
Revbumping may be required upon request from a package maintainer. Additional reasons to perform revbumps are outlined at the Ebuild revisions page in the development guide.
Procedure
Revbumps usually accompany changes to other files in the tree, such as files under files/.
Bumping files
When making changes that require a revbump, those changes should not be made in place. Instead, the following steps should be followed:
- Copy the latest revisions of the files.
- Increment their revision numbers.
- Add any modifications to these copies.
app-editors/vim-core/files/ ├── vimrc-r5 └── vimrc-r6
app-editors/vim-core/files/
├── vimrc-r5
├── vimrc-r6
└── vimrc-r7
For files that do not have revision numbers, append -r1:
app-editors/neovim/files/ └── sysinit.vim
app-editors/neovim/files/
├── sysinit.vim
└── sysinit.vim-r1
These files are not used in any ebuilds yet. The next section explains how to create new ebuilds that use these files.
Bumping ebuilds
Similarly to files, ebuild changes that require a revbump should be applied to copies of those ebuilds, not the original ebuilds. The following steps should be followed:
- For each package, copy the latest stable and unstable ebuild.
- Increment the copies' revision numbers.
- Destabilize these copies.
- Modify the copied ebuilds to use the bumped files from before.
These steps are explained in detail in the following sections.
Copying the ebuilds
Ideally, only the latest stable and unstable version of each package should be revbumped, in order not to clutter the Portage tree.
The ebuild files themselves need to be inspected to determine their stability. Unstable versions have ~ in front of each architecture in the KEYWORDS variable:
app-editors/vim-core/vim-core-9.1.0366.ebuildKEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux ~arm64-macos ~ppc-macos ~x64-macos ~x64-solaris"
Stable versions lack ~ in front of some architectures:
app-editors/vim-core/vim-core-9.0.2167.ebuildKEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~amd64-linux ~x86-linux ~arm64-macos ~ppc-macos ~x64-macos ~x64-solaris"
Live ebuilds should be modified in place; not copied.
Incrementing the ebuild revisions
The same rules apply as in section Bumping files, except that the revision numbers belong before the file extensions.
app-editors/vim-core/ ├── files │ ├── vimrc-r6 │ └── vimrc-r7 ├── metadata.xml ├── vim-core-9.0.2092.ebuild ├── vim-core-9.0.2167.ebuild ├── vim-core-9.1.0366.ebuild └── vim-core-9999.ebuild
app-editors/vim-core/ ├── files │ ├── vimrc-r6 │ └── vimrc-r7 ├── metadata.xml ├── vim-core-9.0.2092.ebuild ├── vim-core-9.0.2167-r1.ebuild ├── vim-core-9.0.2167.ebuild ├── vim-core-9.1.0366-r1.ebuild ├── vim-core-9.1.0366.ebuild └── vim-core-9999.ebuild
The modifications to these new ebuilds and the live ebuilds are explained in the following two sections.
Destabilizing the new ebuilds
~ should be present in front of each arch that does not already have some prefix in KEYWORDS.
KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~amd64-linux ~x86-linux ~arm64-macos ~ppc-macos ~x64-macos ~x64-solaris"
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux ~arm64-macos ~ppc-macos ~x64-macos ~x64-solaris"
Using the bumped files
Find lines that reference the files that were bumped. Modify these to reference the new files. For example:
newins "${FILESDIR}"/vimrc-r6 vimrc
newins "${FILESDIR}"/vimrc-r7 vimrc
Another example:
doins "${FILESDIR}"/sysinit.vim
newins "${FILESDIR}"/sysinit.vim-r1 sysinit.vim