7743050d69
If SPM repository changes are not allowed when a package needs to be bumped, the package won't be bumped/recompiled. However, there is a case in where the SPM repo change constraint loses its importance, and it's when the current SPM repository no longer contains the target package (thus, changes have been upstreamed or they're just not needed anymore). Using "spm-repository-change-if-upstreamed: yes" makes possible to ignore SPM repo changes in this case. The default behaviour does not change, spm-repository-change-if-upstreamed is disabled by default (== no as default config value).
90 lines
3.0 KiB
Plaintext
90 lines
3.0 KiB
Plaintext
# Entropy Matter, Automated Entropy Packages Build Service, example spec file
|
|
|
|
# List of packages required to be built.
|
|
# Comma separated, example: app-foo/bar, bar-baz/foo
|
|
# Mandatory, cannot be empty
|
|
packages: sys-libs/zlib, asd-foo/foo
|
|
|
|
# Entropy repository where to commit packages
|
|
# Mandatory, cannot be empty
|
|
repository: community0
|
|
|
|
# Allow Source Package Manager (Portage) repository change?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
spm-repository-change: yes
|
|
|
|
# In case of Source Package Manager repository change, allow
|
|
# execution if the original repository does not contain
|
|
# the package anymore?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
spm-repository-change-if-upstreamed: yes
|
|
|
|
# Allow compiling package even if it's not actually installed on system?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
not-installed: no
|
|
|
|
# Allow dependencies to be pulled in?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
dependencies: yes
|
|
|
|
# Allow package downgrade?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
downgrade: no
|
|
|
|
# Allow package rebuild?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
rebuild: no
|
|
|
|
# Make possible to continue if one or more packages fail to build?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
keep-going: yes
|
|
|
|
# Allow new USE flags?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
new-useflags: no
|
|
|
|
# Allow removed USE flags?
|
|
# Valid values are either "yes" or "no"
|
|
# Default is: no
|
|
removed-useflags: yes
|
|
|
|
# Package pre execution script hook, executed for each package
|
|
# Valid value is path to executable file
|
|
# Env vars:
|
|
# MATTER_PACKAGE_NAME = name of the package that would be built
|
|
# pkgpre: /home/fabio/repos/entropy/services/matter_examples/pkgpre.sh
|
|
|
|
# Package build post execution script hook, executed for each package
|
|
# Valid value is path to executable file
|
|
# Env vars:
|
|
# MATTER_PACKAGE_NAME = name of the package that would be built
|
|
# To the pkgpost hook, is given one argv parameter, corresponding to the
|
|
# build exit status, which is 0 for no issues, != 0 for issue.
|
|
# If pkgpost hook returns != 0 exit status, this will replace the exit status
|
|
# of the build procedure, which gets returned by build caller (so you have a
|
|
# good change of making the whole matter execution abort).
|
|
# pkgpost: /home/fabio/repos/entropy/services/matter_examples/pkgpost.sh
|
|
|
|
# Env vars:
|
|
# MATTER_PACKAGE_NAME = name of the package that would be built. It does
|
|
# not reflect the name of the failing package, because it could be just a
|
|
# dependency of it.
|
|
# MATTER_PORTAGE_FAILED_PACKAGE_NAME = exact name (atom, CPV) of the failing
|
|
# package, the one that triggered the buildfail hook.
|
|
# MATTER_PORTAGE_REPOSITORY = Portage repository from where the package
|
|
# comes from
|
|
# MATTER_PORTAGE_BUILD_LOG_DIR = directory containing all the build logs of
|
|
# the failed package
|
|
# buildfail: /home/fabio/repos/entropy/services/matter_examples/buildfail.sh
|
|
|
|
# For more info regarding exported environment variables, please see:
|
|
# matter --help
|