A tool to manage rebuilding of AUR packages based on their dependencies.
The general idea is: For an AUR package foo, that depends on bar, you always want to rebuild foo everytime bar is update. This tool makes this easily possible:
- Create rules for packages with other packages that will trigger a rebuild
- System rules: System-wide rules, to work for any user
- can be created by users and applications. This way packagers can provide the required dependencies, without actually depending on this package (i.e. opt depend)
- User rules: created by the user, can override system rules. Only work when sudoing as that user
- System rules: System-wide rules, to work for any user
- Pacman hook to detect packages that need a rebuild after an update
- works recursivly, i.e. if A dependes on B and B on C, C will trigger B and A
- Automatic detection of successful rebuilds
- Works with any pacman frontend that supports the default pacman syntax
- yay, trizen, pacaur and yaourt work out of the box
- other frontends can be set via a command
- allows "waved" rebuilds for frontends that are unable to correctly order packages for the rebuild
The tool is provided as AUR package: repkg
This repository also has a sample repkg rule for itself.
As a user, you can create rules by calling:
repkg create <package> [dependencies...]
package
is the AUR package that should be rebuild, when one of the given dependencies
is updated to a newer versions. You can also create rules directly by creating a rule file in ~/.config/repkg/rules
, with the package name beeing the filename (i.e. package.rule
) and the content beeing the dependencies, space seperated.
For system admins, when running this command as root, the rules are instead written to /etc/repkg/rules
. For repkg prior to version 1.3.0
this will overwrite the rules created by installed packages. But since 1.3.0
packages should place their rules in /etc/repkg/rules/system
to prevent such conflicts.
When updating packages via pacman (or any frontend), rebuilds are automatically detected. You will see a message with all packages that need rebuilds at the end. You can also run
repkg list detail
to show all packages that need rebuilds.
To actually rebuild them, simply run
repkg
This will start the frontend of your choice (e.g. yay, trizen, pacaur, yaourt, ...) and rebuild all required packages.
Simply add a rule file to your PKGBUILD, and install it to /etc/repkg/rules/system
(or /etc/repkg/rules
if you want to be compatible with versions of repkg before 1.3.0
). Assuming your package is name my-pkg
and should be rebuild when dep-a
or dep-b
is updated, the file must be named my-pkg.rule
and contain:
dep-a dep-b
Add repkg as (optional) dependency, and your good to go.
If you want the package to only be updated if the change is significant enough (i.e. a major version update), you can do so by adding a version filter expression to the dependency. These special filters tell repkg to only compare parts of the version numbers, not the whole number. The general syntax for that is:
<package>[=<filter>]
Leaving out the filter means that the package is always rebuilt if the version string changes in any way. Possible filter expressions are:
0
: Only update if the epoche changes. E.g. from1:2.3.5
to2:1.0.0
.v
: Only update if the epoche or the version number itself changes. This exlcudes the package revision and possible suffixes. E.g. from1.2.3
to1.2.4
1..*
(any other positive number besides 0): Same asv
, but limit the version segments to check. E.g. if specifying1
, Only major version updates (1.2.3
to2.0.0
) trigger a rebuild. With2
this also includes minor versions etc.s
: Only update if the epoche or the version number itself changes. This includes the package revision and possible suffixes. E.g. from1.2.3-alpha
to1.2.3
r
: Always update, even if only the package revision changes. E.g.1.2.3-1
to1.2.3-2
:<offset>[:<length>]
: Do a normal string based comaprison, but only compare a substring of the version number, starting atoffset
andlength
characters long (both must be 0 or positive integers). E.g.:2:4
on1.2345.6
will reduce the string to2345
before comparing.:<offset>[:<length>]::<filter>
: Same as before, but instead of a string compare, use another filter. Can be any of the above except the two range limiters. E.g. using the filter:1::v
onv1.2.3
will reduce the string to1.2.3
and then do a normal version compare. Without the previous removal of thev
, a version-based compare would not work for this example.