SRPM Macros

We provide custom Source RPM (SRPM) macros to ease packaging and better integrate our workflow. Please use these macros when possible in Terra.

These are provided in the anda-srpm-macros package. If you use them, make sure to add anda-srpm-macros as a BuildRequires: in the spec file.

You may need to refer to the Terra packaging guidelines for non-macro related Terra guidelines. If you're looking for documentation on our MetaInfo macros, check that out here.

If you would like to contribute to these macros, check out the SRPM macros repository (opens in a new tab).

For upstream macros available in Fedora/Terra, check out our unofficial macros list.

Directories

These macros define certain system directories, and SHOULD be used in place of the raw directory path.

%_appsdir

Expands to: %_datadir/applications or /usr/share/applications

This may seem like a directory to place the application itself into, but this directory is used for application's .desktop files.

%_bun_cache_dir

The directory where Bun cache files are stored in.

Expands to: %{_bun_home}/install/cache

Used for Bun macros.

%_bun_home

The directory where Bun files are stored in. Unfortunately, Bun doesn't actually have a way to enforce this yet. However the proposed environment variable is $BUN_HOME, so we have this for the future.

Expands to: %{rpmbuilddir}/.bun

Used for Bun macros.

%_cargo_home

Set by our Cargo prep macros.

We set this specifically because in online builds if the directory is manually changed as a build step (such as multi Crate repo projects), the Crates could be redownloaded during build and slow down build times. Tools like Tauri also read .cargo differently because they change the current working directory.

Expands to: %{rpmbuilddir}%{?buildsubdir:/%{buildsubdir}}/.cargo

%_deno_dir

The directory that Deno's files and cache are stored in.

Expands to: %{rpmbuilddir}/.deno

Used for Deno macros.

%_deno_install_root

Directory where Deno installs dependency packages.

Expands to: %{_deno_dir}/bin

Used for Deno macros.

%_dracut_confdir

The directory where Dracut config provided by system packages should be installed to.

Expands to: %{_prefix}/lib/dracut/dracut.conf.d

%elvish_completions_dir

Expands to: %_datadir/elvish/lib/completions

Used in %pkg_completions, or manually when %pkg_completions cannot be used.

%_gnomeextensionsdir

Expands to: %{_datadir}/gnome-shell/extensions%{?uuid:/%{uuid}}

%_hicolordir

Expands to: %_iconsdir/hicolor or /usr/share/icons/hicolor

The directory that SHOULD be used when installing application .png files. Note that you then MUST install the (typically app icon) file to the apps folder within the fixed-size directory in %_hicolordir.

For example:

# Lets say package 'foo' has a 16x16 and 64x64 .png
install -Dm644 icons/16x16.png %{buildroot}%{_hicolordir}/16x16/apps/%{name}.png
install -Dm644 icons/64x64.png %{buildroot}%{_hicolordir}/64x64/apps/%{name}.png

If the file is an .svg, use the %_scalableiconsdir.

%_npm_cache_dir

Expands to: %{rpmbuilddir}/.npm

Used with JavaScript package manager macros, especially NPM macros.

%nushell_completions_dir

Expands to: %_datadir/nushell/vendor/autoload

Used in %pkg_completions, or manually when %pkg_completions cannot be used.

%_nvm_dir

The location in the %{rpmbuilddir} what will be passed to $NVM_DIR, which is where vendored Node.js installs and cache are stored.

Expands to: %{rpmbuilddir}/.nvm

Only used for for %{__nvm}.

%_pkgconfigdir

Expands to: %{_libdir}/pkgconfig

Used in the %files section.

%_pnpm_home

The directory where PNPM files and cache are stored.

Expands to: %{rpmbuilddir}/.pnpm

Used for PNPM macros.

%_pnpm_store

The directory where JavaScript modules installed by PNPM usually go. This will usually not be produced when using PNPM as a build tool, but exists for rare builds it may be created in.

Expands to: %{_pnpm_home}/store

Used for PNPM macros.

%rpmbuilddir

This macro exists because Terra supports EL distributions (Red Hat Enterprise Linux, Alma Linux, etc.) which currently have an RPM version from before the %{builddir} change to address issues like this (opens in a new tab).

One, albeit clunky, solution is to define %{builddir} manually as %{_builddir} in specs targeting distros with different versions of RPM where one has a version older than 4.20. We have this macro instead to make the process easier without overriding any builtin RPM macros. For more information on this solution, see these (opens in a new tab) comments (opens in a new tab) on the issue linked above.

This macro is subject to deprecation once all EL distributions with an RPM version older than 4.20 are end-of-life (likely when EL10 is end-of-life), or in the event we can no longer support EL distributions this old.

Expands to: %{?builddir}%{?!builddir:%{_builddir}}

%_rustup_home

This macro is set by %rustup_nightly.

It sets a specific location for Rustup install files so the toolchain information is never potentially lost during different build steps and to keep files out of $HOME.

Expands to: %{rpmbuilddir}/.rustup

%_scalableiconsdir

Expands to: %_hicolordir/scalable/apps or /usr/share/icons/hicolor/scalable/apps The directory that SHOULD be used when installing application .svg files to. You do not need to specify any folders for this macro, the file can be added to the end of this macro. For example:

install -Dm644 icons/%{name}.svg %{buildroot}%{_scalableiconsdir}/%{name}.svg

If the file is a .png, use %_hicolordir.

%_yarn_cache_dir

The directory where Yarn cache files are stored in.

Expands to: %{rpmbuilddir}/.yarn

Used for Yarn macros.

Desktop File Macros

These are macros used for working with .desktop files (opens in a new tab).

%__desktop_file_edit

Expands to: /usr/bin/desktop-file-edit

%__desktop_file_install

Expands to: /usr/bin/desktop-file-install

%__desktop_file_validate

Expands to: /usr/bin/desktop-file-validate

%__update_desktop_database

Expands to: /usr/bin/update-desktop-database

%desktop_file_edit

SHOULD be used if you for any reason need to edit a .desktop file a build has already installed.

Available flags:

• -f <argument>: MAY be used to specify the file, but is actually OPTIONAL if you list the file path after the macro and all other flags.
• -k <argument>: List the "keys" to change (Exec, Icon, etc.). Comma separated for multiple keys.
• -v <argument>: List the "values" to set for keys you are changing. Comma separated for multiple keys. MUST be listed in the same corresponding order the keys are listed in.
• -u <argument> MAY be used to set either %u or %U in the desktop file. If using this you MUST NOT use u as a macro name for any reason.
  • %u means that a desktop file can only read one URL at a time, %U means that it can read multiple at a time. These are what are known as exec keys (opens in a new tab).
  • Defer to what the desktop file originally contained if you are unsure which to use.

Example usage:

%desktop_file_edit -k Exec,Icon -v pkg,pkgicon -u %u -f /path/to/file.desktop

%desktop_file_install

SHOULD be used to install a .desktop file.

Available flags:

• -f <argument>: MAY be used to specify the file, but is actually OPTIONAL if you list the file path after the macro and all other flags.
• -k <argument>: List the "keys" to change (Exec, Icon, etc.). Comma separated for multiple keys.
• -v <argument>: List the "values" to set for keys you are changing. Comma separated for multiple keys. MUST be listed in the same corresponding order the keys are listed in.
  • Example: %desktop_file_install -k Exec -v /usr/bin/pkg /path/to/filetoedit.desktop
• -u <argument> MAY be used to set either %u or %U in the desktop file. If using this you MUST NOT use u as a macro name for any reason.
  • %u means that a desktop file can only read one URL at a time, %U means that it can read multiple at a time. These are what are known as exec keys (opens in a new tab).
  • Defer to what the desktop file originally contained if you are unsure which to use.

Example usage:

%desktop_file_install -k Exec,Icon -v pkg,pkgicon -u %u -f path/to/file.desktop

%desktop_file_validate

SHOULD be used if you for any reason need to edit a .desktop file a build has already installed.

Available flags:

• -f <argument>: MAY be used to specify the file, but is actually OPTIONAL if you list the file path after the macro.

Example usage:

%desktop_file_validate -f path/to/file.desktop

%update_desktop_database

A post/postun script to update the .desktop database on install/uninstall of the package. Is most likely not necessary for most things.

Expands to: %{__update_desktop_database} --quiet || :

Go

These macros assist with building Go (opens in a new tab) projects.

%goprep_online

MAY be used to prep a Go package for online builds. Replaces %goprep in %prep.

JavaScript

These are macros to assist with the general packaging of applications that are written in JavaScript and/or use JavaScript runtimes such as Node.js or Bun.

Node.js Macros

Macros for using Node.js (opens in a new tab). These require the use of Fedora Node.js macros (opens in a new tab) in the nodejs-packaging package.

%__nvm

Calls NVM (Node Version Manager) while setting $NVM_DIR. Only used if vendoring Node.js.

Expands to: /usr/bin/env NVM_DIR=%{_nvm_dir} /usr/bin/nvm

%vendor_nodejs

This macro SHOULD only be used if Node.js packages available from the repos are not usable for some reason.

Available flags:

• -v <argument> is REQUIRED for this macro to pass the version to NVM. This flag accepts a full version, the major for the latest of a major version of Node.js (e.g., 24), or node to use the latest version of Node.js available.

Usecase examples:

• Fedora has not yet packaged the correct version of Node.js or the required version is older than what is supplied.
  • This means that packaged Node modules will probably not meet their runtime requirements, but Electron apps may be fine.
• EL does not yet have the correct version of Node.js.
  • This poses the same concern as above.

For this reason, whatever you are packaging SHOULD be tested locally upon a successful build to see if it has any runtime issues.

What %vendor_nodejs does:

1. Installs the desired Node.js version to %{_nvm_dir}.
2. Redefines %{__nodejs} to run the vendored version through NVM.
3. Sets a %bcond to vendored_nodejs so other macros will use the vendored version.

Vendored versions of NPM and NPX are subject to limitations in commands as they must be run through exec.

Node Module Macros

Macros for packaging Node modules.

%npm_prep

Prepare a Node module for build steps.

Available flags:

• -n <argument> MUST be used to define %{npm_name} if it was not defined as a global macro.

%fetch_node_tests

Fetch self-tests from a Git repo. MUST include all necessary test files and folders. If used, it SHOULD be placed in the %prep section.

Available flags:

• -u <argument> MUST be used to define the URL if the one listed in the URL: tag for the package is not detectable as clonable.

All necessary test files and folders MUST be listed after the macro. Test folders MUST start with /.

Example usage:

%prep
%npm_prep
%fetch_node_tests -u https://github.com/dev/module.git /tests .eslintrc

%npm_install

Install a Node module to %{npm_sitelib} and symlink its executable.

Real package example:

%install
%npm_install -s license-checker
 
# Bootstrap the license fetching
# Environment variable is one set during execution of %%npm_install
./bin/%{npm_name}$_js --limitAttributes licenses --out LICENSE.modules

%node_self_test

Runs self-defined tests on the Node module. This is not applicable for all Node modules. Also, not all tests (that are supported as Node modules) can use a wide variety of testing tools. For use in %check.

Available flags:

• -R: Direct duplicate of an -R flag. Project dependent.
• -v: Direct duplicate of a -v flag. Project dependent.

You MUST use %fetch_node_tests first if using this.

%__npm_license_checker

Expands to: /usr/bin/license-checker

Runs the NPM license-checker command, documented here (opens in a new tab).

Example output:

/usr/bin/license-checker
└─ @fyralabs/devdocs@@0.0.1
   ├─ licenses: MIT
   ├─ repository: https://github.com/FyraLabs/devdocs
   ├─ publisher: Lleyton Gray
   ├─ email: lleyton@fyralabs.com
   ├─ path: /home/owen/Documents/Projects/devdocs
   └─ licenseFile: /home/owen/Documents/Projects/devdocs/LICENSE

%npm_license

Expands to: /usr/bin/license-checker --limitAttributes licenses

This is similar to %__npm_license_checker, but limits the output to only the license.

Available flags:

• -o <argument> MAY be used as a shorthand for --out.

Example output:

/usr/bin/license-checker --limitAttributes licenses
└─ @fyralabs/devdocs@@0.0.1
   └─ licenses: MIT

SHOULD be used if packaging Node modules.

Example usage:

%{npm_license} --out LICENSE.modules

OR:

%npm_license -o LICENSE.modules

The above would create a LICENSE.modules file which can then be packaged using %license LICENSE.modules.

%npm_license_summary

Outputs a summary of the bundled licenses. Useful for determining what to put in the License: section for Node modules.

Expands to: %{__npm_license_checker} --summary

JavaScript Package Managers

These are macros for working with JavaScript package managers.

NPM Macros

Macros for using NPM (opens in a new tab).

%__npm_log_level

Macro that sets the logging level for NPM. Defaults to error because NPM logs can fill the terminal quickly.

If desired, it can be redefined to silent, warn, notice, info, verbose, or silly.

%npm_common_envvars

Expands to: NPM_CONFIG_USERCONFIG=%{rpmbuilddir}/.npmrc NPM_CONFIG_GLOBALCONFIG=%{rpmbuilddir}/npmrc NPM_CONFIG_CACHE=%{_npm_cache_dir} NPM_CONFIG_LOGLEVEL=%{__npm_log_level} NPM_CONFIG_FUND=false NPM_CONFIG_UPDATE_NOTIFIER=false NO_UPDATE_NOTIFIER=1 NPM_CONFIG_COLOR=always NPM_CONFIG_INIT_MODULE=%{rpmbuilddir}/.npm-init.js

What these do:

• Forces all configuration files into the %{rpmbuilddir} so they are easily locatable and to prevent attempting to write to the host file system for global config.
• Sets the NPM log level to errors (previously warn but this included warnings irrelevant to builds or Node modules).
• Disables funding notifications as this does not make sense to display in an automated build and causes log spam.
• Disables update notifications since we are using a packaged version of NPM unless using %vendor_nodejs.
• Sets color to always for more easily readable logs.

%npm_config_opts

Explicit NPM configuration flags of the environment variables set by the Macros.

Expands to: --userconfig=%{rpmbuilddir}/.npmrc --globalconfig=%{rpmbuilddir}/npmrc --cache=%{_npm_cache_dir} --loglevel=%{__npm_log_level} --fund=false --update-notifier=false --color=always --init-module=%{rpmbuilddir}/.npm-init.js

%__npm

Macro to call NPM with predetermined enviroment variables.

Expands to: /usr/bin/env %{npm_common_envvars} %{?with_vendored_nodejs:%{__nvm} exec npm --}%{!?with_vendored_nodejs:/usr/bin/npm}

SHOULD be used in place of calling npm itself.

%__npx

Remotely run Node modules with NPX.

Expands to: /usr/bin/env %{npm_common_envvars} %{?with_vendored_nodejs:%{__nvm} exec npx --}%{!?with_vendored_nodejs:/usr/bin/npx}

%npm_audit

Audit with NPM if package uses bundled Node module dependencies. For use in the %check section.

Vulnerabilities for Node modules not bundled in the final package SHOULD NOT be fixed. If a vulnerability is found only in build dependencies, you are fine to leave it as is.

%npm_audit_fix

Fix vulnerabilities found using %npm_audit. Should be used in %prep section.

Installed packages with fixed dependencies SHOULD be tested first to make sure the applied fix did not cause any issues.

Available flags:

• -d will run with --dry-run so you can check what the fix would do.
• -f will run with --force, ignoring package locks or other requirements set by the module to fix the dependencies. This MUST be tested locally and verified to not cause breakage.
• -o <argument> will omit a dependency or group (such as dev) from being fixed.
• -O <argument> will only fix a specified depency or group.
• -p will limit the run to the package lock.

LIMITATION: Cannot be used on modules installed using the -g flag (which is done in %npm_prep) which use a package lock.

%npm_test

Runs NPM tests. This will not be applicable to all projects or Node modules. For use in the %check section. For some projects it may be necessary to export NODE_ENV=test first.

Expands to: %{__npm} test

Bun Macros

Macros for using Bun (opens in a new tab).

%bun_common_envvars

Sets the $BUN_HOME for future use and sets the cache dir.

Expands to: %{npm_common_envvars} BUN_HOME=%{_bun_home} BUN_INSTALL_CACHE_DIR=%{_bun_cache_dir} BUN_RUNTIME_TRANSPILER_CACHE_PATH=%{_bun_cache_dir} FORCE_COLOR=1

%bun_config_opts

Explicit Bun configuration flags of the environment variables set by the Macros.

Expands to: --cache-dir=%{_bun_cache_dir}

%__bun

Expands to: /usr/bin/env %{bun_common_envvars} /usr/bin/bun

SHOULD be used in place of calling bun itself.

%__bunx

Run JavaScript modules (downloading them if necessary) with Bun.

Expands to: /usr/bin/env %{bun_common_envvars} /usr/bin/bunx

SHOULD be used in place of calling bunx or bun x itself.

%bun_audit

Audit with Bun if package uses bundled JavaScript module dependencies. For use in the %check section.

You SHOULD NOT need to fix vulnerabilities for JavaScript modules that are not bundled in the final package. This means if a vulnerability is found only in build dependencies, you are fine to leave them be.

%bun_pm_trust

Add JavaScript modules to trusted dependencies so their postinstall scripts can be run. Requires arguments for dependencies to approve. SHOULD only be used if necessary.

Available flags:

• -a can be used to trust all dependencies, otherwise simply list the dependencies you want to trust after the command.

Expands to: %{__bun} pm trust

%bun_test

Runs Bun tests. This will not be applicable to all projects. For use in the %check section. For some projects it may be necessary to export NODE_ENV=test first.

Expands to: %{__bun} test

Deno Macros

Macros for using Deno (opens in a new tab).

%deno_common_envvars

Sets the $DENO_DIR, $DENO_INSTALL_ROOT, limits $DENO_JOBS to ${RPM_BUILD_NCPUS}, disables update notifications, and forces color.

Expands to: %{npm_common_envvars} DENO_DIR=%{_deno_dir} DENO_INSTALL_ROOT=%{_deno_install_root} DENO_NO_UPDATE_CHECK=1 DENO_JOBS=${RPM_BUILD_NCPUS} FORCE_COLOR=1

%__deno

Expands to: /usr/bin/env %{deno_common_envvars} /usr/bin/deno

SHOULD be used in place of calling deno itself.

%__dx

Call modules directly with DX/Deno X.

Expands to: /usr/bin/env %{deno_common_envvars} /usr/bin/dx

SHOULD be used in place of calling dx or deno x itself.

%deno_audit

Audit with Deno if package uses bundled JavaScript module dependencies. For use in the %check section.

Expands to: NPM_CONFIG_AUDIT_LEVEL=low %{__deno} audit --level=low --ignore-unfixable --socket

%deno_approve_scripts

Approve dependency scripts with Deno if needed. Requires arguments for dependencies to approve. SHOULD only be used if necessary.

Available flags:

• -l will limit approval to only dependencies found in the package lock.

Expands to: %{__deno} approve-scripts

%deno_test

Runs Deno tests. This will not be applicable to all projects. For use in the %check section. For some projects it may be necessary to export NODE_ENV=test first.

Expands to: %{__deno} test --parallel

PNPM Macros

Macros for using PNPM (opens in a new tab).

%pnpm_common_envvars

Sets the NPM environment variables and the PNPM home directory.

Expands to: %{npm_common_envvars} PNPM_HOME=%{_pnpm_home}

%__pnpm

Expands to: /usr/bin/env %{pnpm_common_envvars} %{?with_vendored_pnpm:%{_pnpm_home}/pnpm}%{!?with_vendored_pnpm:/usr/bin/pnpm}

SHOULD be used in place of calling pnpm itself.

%__pnpx

Remotely execute JavaScript modules using PNPX.

Expands to: /usr/bin/env %{pnpm_common_envvars} /usr/bin/pnpx

SHOULD be used in place of calling pnpx or pnpm dlx itself.

%vendor_pnpm

This SHOULD only be used if PNPM is not usable/available from the available repositories.

Available flags:

• -v <argument> MAY be used to define a desired version of PNPM.

Usecase examples:

• Fedora's currently packaged PNPM is too old for the build.
• You want to make the package build on EL (does not have PNPM).
  • In this case, you SHOULD wrap %vendor_pnpm in %if macros such as:

  •  %if %{defined rhel}
     %vendor_pnpm
     %endif

%pnpm_audit

Audit with PNPM if the package uses bundled JavaScript module dependencies. For use in the %check section.

You SHOULD NOT need to fix vulnerabilities for JavaScript modules that are not bundled in the final package. This means if a vulnerability is found only in build dependencies, you are fine to leave them be.

%pnpm_audit_fix

Fix security issues in dependencies using PNPM.

Expands to: NPM_CONFIG_AUDIT_LEVEL=low %{__pnpm} audit

%pnpm_approve_builds

Approve dependency scripts with PNPM if needed. Requires arguments for dependencies to approve. SHOULD only be used if necessary.

Available flags:

• -g can be used to trust depdendencies of globally installed packages.

Expands to: %{__pnpm} approve-builds

%pnpm_test

Runs PNPM tests. This will not be applicable to all JavaScript modules. For use in the %check section. For some projects it may be necessary to export NODE_ENV=test first.

Expands to: %{__pnpm} test

Yarn Macros

Macros for using Yarn (Yarn Classic/Yarn v1) (opens in a new tab) and Yarn Berry (Yarn Modern/Yarn v2+) (opens in a new tab).

You SHOULD use yarnpkg (Yarn Classic) unless you need yarnpkg-berry (Yarn Berry) specifically.

%yarn_common_envvars

Sets the NPM evironment variables and Yarn's cache folder.

Expands to: %{npm_common_envvars} YARN_CACHE_FOLDER=%{_yarn_cache_dir}

%yarn_config_opts

Explicit Yarn configuration flags of the environment variables set by the Macros.

Expands to: --cache-folder=%{_yarn_cache_dir}

%__yarn

Expands to: /usr/bin/env %{yarn_common_envvars} /usr/bin/yarn

SHOULD be used in place of calling yarn itself.

%__yarn_dlx

Remotely execute a JavaScript module with Yarn DLX.

Expands to: /usr/bin/env %{yarn_common_envvars} /usr/bin/yarn dlx

SHOULD be used in place of calling yarn dlx itself.

%yarn_audit

Audit Yarn if the package uses bundled JavaScript module dependencies. For use in the %check section.

You SHOULD NOT need to fix vulnerabilities for JavaScript modules that are not bundled in the final package. This means if a vulnerability is found only in build dependencies, you are fine to leave them be.

%yarn_test

Runs Yarn tests. This will not be applicable to all projects. For use in the %check section. For some projects it may be necessary to export NODE_ENV=test first.

Expands to: %{__yarn} test

Webapp Macros

Macros for building webapps (opens in a new tab).

Electron

These macros assist with the general packaging of applications that use Electron (opens in a new tab).

%electronmeta

Set up all basic requirements including build macros for building an Electron app.

Available flags:

• -a will pull in additional build dependencies often needed particularly when building with NPM.
  • Currently, this includes nodejs-devel, nodejs-packaging, and typescript.
• -D will disable debuginfo package creation. This is necessary for many Electron apps as the bundled libraries often do not contain enough to strip, meaning this step in the build will fail. SHOULD only be used if debug packages cannot be created.

Rundown of what all %electronmeta does:

• Converts %_target_cpu (the RPM build architecture) into %_electron_cpu, the Electron format for compatible architectures. See the table below for conversions. See also: %electron_arches
  • These are defined because Electron names the build files and directories after the architecture.
  • The macros used to build Electron apps all require this to be set.
  • In some cases, these architectures are used in the source tarballs for Electron projects.
  • This can also be used to help work with the files if you need to do anything manually.
• Defines %__provides_excludes to make sure Electron apps are not flagged as providers of their bundled dependencies, such as FFmpeg libraries.
• Defines %__requires_excludes based on architecture to prevent Electron projects' cross-platform builds from causing false dependency positives from RPM.
• If using the -D boolean, sets %debug_package to %{nil} to prevent stripping of bundled libraries and/or build failures due to not enough data to strip.
• Sets the build and runtime dependencies.
• Sets the ExclusiveArch: tag to only the architectures Electron supports.
• Defines a %bcond for whether or not Electron is bundled for other macros.
• Defines the bundled dependencies as bundled.
  ⚠️

  This only defines Electron's bundled dependencies, not any JavaScript modules the app may also bundle.

This ensures packagers don't need to manually set these for every Electron app's spec, hopefully eliminating depsolver problems and helping reduce common build issues.

Like other meta macros (e.g., %forgemeta from Fedora), you MUST be mindful of where in the spec this macro should be placed.

• MUST always come after Name: is defined and before the %description section.
• SHOULD come before the License: field if using %{electron_license}.
• MAY be used under preambles but before %description if not using %{electron_license}.

The safest location is under Name: and above other preambles. When in doubt, place the macro here.

Example usage:

Name:    electron
%electronmeta
Version: 39.2.7

%electron_arches

The architectures Electron supports. Automatically set as ExclusiveArch: when using %electronmeta.

As written, the macro expands to:

• %{x86_64} %{ix86} %{arm64} armv7l armv7hl armv7hnl %{mips64}

Which expands fully to:

• x86_64 x86_64_v2 x86_64_v3 x86_64_v4 amd64 em64t i386 i486 i586 i686 pentium3 pentium4 athlon geode aarch64 armv7l armv7hl armv7hnl mips64 mips64el mips64r6 mips64r6el

Which simply means Electron supports x86_64 (opens in a new tab), 32-bit x86 (AKA: IA-32) (opens in a new tab), AArch64/ARM64 (opens in a new tab), ARMv7 (AKA: armhf) (opens in a new tab), and MIPS64 (opens in a new tab).

However, at this time, Terra only supports x86_64, AArch64, and 32-bit x86.

%electron_license

The license for bundled Electron. NOT set by default in %electronmeta because you cannot set the license field twice. MAY be used in combination with manually adding the other relevant licenses (if this is done, a proper license tag would be License: XXX-x.x AND %{electron_license}).

%electronmeta SHOULD be used BEFORE the License: preamble but AFTER Name: if using this macro.

%electron_install

Install files of apps built using Electron Builder or Electron Forge. MUST be used after an appropriate build macro.

Capital letter flags denote use with desktop file (opens in a new tab) installation.

By default, the install steps are:

1. Make the install directory.

• This will be in the %{_libdir} (/usr/lib on 32-bit architectures and /usr/lib64 on 64-bit ones).
• This is done because programs with bundled dependencies (Electron, JavaScript modules, and more) MUST have these dependencies kept together.

2. Install the app's files.
3. Symlink the app's binary to the bin directory.
4. Install the app's icons.

Available flags:

• -b <argument> MUST be used when the app's executable differs from the name of the package.
• -d <argument> MAY be used to install the app under a different directory than the name of the package.
• -i <argument> MUST be used when the app's desktop file points to an icon name different from the name of the package.
• -I <?argument> MAY be used to handle automatic icon installation. It can be used to point to either the folder icons are in and the icon files themselves. You MUST include the file extension if pointing it to the icon files, otherwise it will assume you are pointing it to a directory.
• -l MAY be used to fetch all licenses including the bundled ones and put them in a directory called bundled_licenses. You SHOULD then package them in the license directory using %license bundled_licenses/* in the %files section.
  • If using this you MUST make sure there are no duplicate license names. For example, if the main application's license file is LICENSE, but one of its bundled license files is also LICENSE, you SHOULD rename the bundled license to an appropriate name indicating it is the license for a bundled dependency.
  • An appropriate name would be something like LICENSE.bundleddepname or bundleddepname.LICENSE. Usually, the former is used, but you MAY use either format.
  • This MUST be done because if there are two different files with the same name, the cp command used in the %license macro for the files section will either fail or overwrite the main software's license, which is not admissible for redistribution.
• -s <argument> MAY be used to choose the name of the symlink.
• -S <argument> MAY be used to create an additional symlink with a different name. Useful when an app has two interchangeable common names.
• -D MAY be used to handle automatic installation of the .desktop file. This ONLY works if Electron Builder builds an AppImage, and should not be used if the source contains a desktop file.
• -E <argument> MAY be used to set the "--enable-features" flag in the desktop file. Features to enable MUST be comma separated without spaces.
• -O <?argument> MAY be used to set the Ozone platform (opens in a new tab) the Electron app will run on. If no arguments are supplied, it will fall back to --ozone-platform-hint=auto. Accepted arguments are -Ox11 and -Owayland
• -U <argument> MAY be used to set either %u or %U in the desktop file. If using this you MUST NOT use u as a macro name for any reason.
  • %u means that a desktop file can only read one URL at a time, %U means that it can read multiple at a time. These are what are known as exec keys (opens in a new tab).
  • Defer to what the desktop file originally contained if you are unsure which to use.

Example usage:

• The command %electron_install -b app -i app -s app -S alsoapp -D -Owayland -U %u -E WaylandWindowDecorations would install the program with:
  • Icons named app.png.
  • A symlink named app.
  • A second symlink called alsoapp.
  • A desktop file with the Exec line reading Exec=/usr/lib(64)/pkgname/app --enable-features=WaylandWindowDecorations --ozone-platform=wayland %u.

Tauri Macros

Macros for using Tauri (opens in a new tab).

Tauri apps always require JavaScript package managers AND Cargo, so for this reason the Rust macros are also relevant.

%tauri_buildrequires

MAY be used in a spec by setting BuildRequires: %{tauri_buildrequires}

Available flags:

• -a: Additional BuildRequires that may be needed for some projects.
  • Currently, this includes nodejs-devel, nodejs-packaging, and typescript.
  • This would be used as BuildRequires: %{tauri_buildrequires -a}.
• -t: Pull Tauri itself from the repos.
  • This would be used as BuildRequires: %{tauri_buildrequires -t}

%tauri_prep

Preps a Tauri package. Wrapper for %cargo_prep_online that checks that the Tauri subdirectory is correct.

Available flags:

• -n <argument>: The name of the subdirectory to cd into before running %cargo_prep_online. This value is also used when setting a macro used in other Tauri macros. If this flag is not passed, the macro will default to the most common name used for this subdirectory which is src-tauri.

%tauri_install

MAY be used to install a built Tauri package. A port of %cargo_install.

Available flags:

• -f <argument>: Should be the same as the features that were passed to the Tauri build. Used for installing the Cargo development files.

%tauri_cargo_license

A port of %cargo_license_online that points to the Tauri app's Cargo.toml.

Available flags:

• -f <argument>: Should be the same as the features that were passed to the Tauri build.

%tauri_cargo_license_summary

A port of %cargo_license_summary_online that points to the Tauri app's Cargo.toml.

Available flags:

• -f <argument>: Should be the same as the features that were passed to the Tauri build.

%tauri_cargo_vendor_manifest

A port of %cargo_vendor_manifest_online that points to the Tauri app's Cargo.toml.

%tauri_generate_buildrequires

Generates BuildRequires for a Tauri build.

Supports the same flags as %tauri_buildrequires.

Configurable Tauri Macros

%__tauri_bundles

By default, all macros which call Tauri do not build bundles. Set %global __tauri_bundles to the bundle(s) you want to change this.

This may be useful for, for example, building an AppImage to extract a .desktop file from.

%__tauri_ignore_version_mismatches

This macro disables Tauri version mismatch checking. It can be set to anything.

System Tauri Macros

These are macros for use with Tauri if installed from the repo. Please note that using Tauri from the repo MAY NOT WORK with all projects unless you override version checking, which is not advisable in most circumstances.

%__tauri

Calls Tauri while setting the Fedora Cargo environment variables.

Expands to: /usr/bin/env CARGO_HOME=%{_cargo_home}%{!?with_rust_nightly: RUSTC_BOOTSTRAP=1}%{?with_rust_nightly: RUSTUP_HOME=%{_rustup_home}} RUSTFLAGS='%{build_rustflags}' /usr/bin/tauri

%tauri_build

Build with system Tauri.

Available flags:

• -f <argument>: Features to enable in Tauri and Cargo. Comma separated.

%tauri_build_crate

A port of %cargo_build_crate (opens in a new tab) for Tauri.

Available flags:

• -f <argument>: Features to enable in Tauri and Cargo. Comma separated.

Webapp Build Macros

These are macros used to build webapps using JavaScript package managers and builders such as Electron Builder (opens in a new tab), Electron Forge (opens in a new tab), Electron Vite (opens in a new tab), or Tauri.

Capital letter flags generally denote options that SHOULD be used with caution or only if necessary for a build.

For more information on each package manager, see NPM Macros, Bun Macros, Deno Macros, PNPM Macros, and Yarn Macros.

%npm_build

SHOULD be used for building Electron or Tauri apps with NPM. Has a great deal of flags to work around NPM specific limitations.

Available flags:

• -c: Run %{__npm} ci instead of %{__npm} install. May be necessary for projects with stricter build dependencies.
• -e <argument>: Execute commands and modules within the NPM build environment. Some commands may need -- in between the command itself and the following arguments. Can accept multiple arguments if they are separated using standard shell separators (; and &&).
• -f <argument>: This option is only for Tauri projects. Features to pass to Tauri/Cargo. Features should be comma separated.
• -r <argument>: Executes %{__npm} run for scripts in the package.json. Can run multiple scripts if they are comma separated.
• -B: Execute the webapp builder (Electron Builder, Electron Forge, or Tauri) directly. Will NOT work for projects that require build steps which use Node.js or executing JavaScript scripts directly.
• -C <argument>: Point NPM to the build config file if it cannot automatically detect it.
• -M <argument>: Mode to use in Electron Vite builds. Accepts production, development, and staging. Note that this differs from $NODE_ENV so you can run any combination of Vite environment modes and Node.js environment modes.
• -V: Execute Electron Vite. Same limitation as with -B.

Example usage:

%build
%npm_build -r script,script2 -e %{__nodejs} tasks/task1.js && %{__nodejs} tasks/tasks2.js -B

The above would run the necessary install steps, run script and script2, execute Node.js to run task1.js and task2.js, then call the build tool.

%bun_build

SHOULD be used to build Electron or Tauri apps with Bun.

Available flags:

• -c: Run %{__bun} ci instead of %{__bun} install. Analogous to %{__bun} install --frozen-lockfile. May be necessary for projects with stricter build dependencies.
• -e <argument>: Execute commands and modules within the Bun build environment. Can accept multiple arguments if they are separated using standard shell separators (; and &&).
• -f <argument>: This option is only for Tauri projects. Features to pass to Tauri/Cargo. Features should be comma separated.
• -v: Run Electron Vite build steps. Not needed for all Electron apps.
• -r <argument>: Executes %{__bun} run for scripts in the package.json. Can accept multiple arguments if they are comma separated.
• -F: Runs --force on the %{__bun} install step. This will assure all dependencies are the latest versions from the registry, reinstalling them if necessary.
• -N: Runs --no-save on the %{__bun} install step. This prevents updating or (re)creating a lockfile to prevent freezing.
• -R: Remove the bun.lock file. SHOULD only be used if the lockfile is causing build issues or upstream builds without a lock file. Built apps using this MUST be carefully tested for problems.

Example usage:

%build
%bun_build -c -r script,script2 -e ng build && echo "Done."

The above would run %{__bun} ci, run script and script2, the JavaScript module executable ng to build with, call echo, then call the build tool.

%deno_build

SHOULD be used to build Electron or Tauri apps with Deno.

Available flags:

• -f <argument>: This option is only for Tauri projects. Features to pass to Tauri/Cargo. Features should be comma separated.
• -t <argument>: Executes %{__deno} task for scripts in the package.json. Can accept multiple arguments if they are comma separated.
• -v: Run Electron Vite build steps. Not needed for all Electron apps.
• -r <argument>: Executes files with %{__deno} run. Can accept multiple arguments if they are comma separated.
• -x <argument>: Execute commands and modules within the Deno build environment. Can accept multiple arguments if they are separated using standard shell separators (; and &&).
• -F: Runs --force on the %{__deno} install step. This will overwite the existing dependency installation (if any exists).
• -N: Runs --no-lock on the %{__deno} install step. This prevents updating or (re)creating a lockfile to prevent freezing.

Example usage:

%build
%deno_build -t script,script2 -r file1.js,file2.js

The above would run run script and script2, then run file1.js and file2.js with Deno before running the build tool.

%pnpm_build

SHOULD be used for building Electron or Tauri apps with PNPM.

Available flags:

• -e <argument>: Execute JavaScript modules or installed programs in the PNPM build environment. Can accept multiple arguments if they are separated using standard shell separators (; and &&).
• -f <argument>: This option is only for Tauri projects. Features to pass to Tauri/Cargo. Features should be comma separated.
• -r <argument>: Executes %{__pnpm} run for scripts in the package.json. Not recommended for Electron Builder/Electron Forge or Electron Vite commands. Can accept multiple arguments if they are comma separated.
• -v: Run Electron Vite build steps. Not needed for all Electron apps.
• -F: Executes the %{__pnpm} install step with --frozen-lockfile. May be necessary for projects expecting very strict build dependencies, but can also override projects that do not enforce a lock.
• -N: Executes the %{__pnpm} install step with --no-frozen-lockfile. Overrides projects that try to enforce a lockfile.
• -R: Makes %{__pnpm} exec run on every project in the worspace recursively. SHOULD be used only if necessary and with caution.

Example usage:

%build
%pnpm_build -N -v -r script,script2

The above would run %{__pnpm} install --no-frozen-lockfile, run script and script2, then call Electron Vite before the build tool.

%yarn_build

SHOULD be used to build Electron or Tauri apps with Yarn or Yarn Berry.

Available flags:

• -e <argument>: Execute JavaScript modules or installed programs in the Yarn build environment.
• -f <argument>: This option is only for Tauri projects. Features to pass to Tauri/Cargo. Features should be comma separated.
• -r <argument>: Executes %{__yarn} run for scripts in the package.json. Not recommended for Electron Builder, Electron Forge, or Electron Vite commands. Can accept multiple arguments if they are comma separated.
• -v: Run Electron Vite build steps. Not needed for all Electron apps.
• -F: Executes the %{__yarn} install step with --frozen-lockfile. May be necessary for projects expecting very strict build dependencies, but can also override projects that do not enforce a lock.
• -N: Executes the %{__yarn} install step with --no-lockfile. Makes Yarn not update the lockfile on dependency installation.

Example usage:

%build
%yarn_build -f wayland,x11

The above would run Yarn build steps and execute a Tauri build with the features wayland and x11.

Other

JavaScript related macros that apply to all or do not fit into any of the above categories.

%set_javascript_build_flags

Set the flags and environment variables used for JavaScript package manager builds.

Based on Fedora's %set_build_flags macro (opens in a new tab).

Expands to:

NPM_CONFIG_USERCONFIG="${NPM_CONFIG_USERCONFIG:-%{rpmbuilddir}/.npmrc}" ; export NPM_CONFIG_USERCONFIG ; \
NPM_CONFIG_GLOBALCONFIG="${NPM_CONFIG_GLOBALCONFIG:-%{rpmbuilddir}/npmrc}" ; export NPM_CONFIG_GLOBALCONFIG ; \
NPM_CONFIG_CACHE="${NPM_CONFIG_CACHE:-%{_npm_cache_dir}}" ; export NPM_CONFIG_CACHE ; \
NPM_CONFIG_LOGLEVEL="${NPM_CONFIG_LOGLEVEL:-%{__npm_log_level}}" ; export NPM_CONFIG_LOGLEVEL ; \
NPM_CONFIG_FUND="${NPM_CONFIG_FUND:-false}" ; export NPM_CONFIG_FUND ; \
NPM_CONFIG_UPDATE_NOTIFIER="${NPM_CONFIG_UPDATE_NOTIFIER:-false}" ; export NPM_CONFIG_UPDATE_NOTIFIER ; \
NPM_CONFIG_COLOR="${NPM_CONFIG_COLOR:-always}" ; export NPM_CONFIG_COLOR ; \
NPM_CONFIG_INIT_MODULE="${NPM_CONFIG_INIT_MODULE:-%{rpmbuilddir}/.npm-init.js}" ; export NPM_CONFIG_INIT_MODULE ; \
BUN_HOME="${BUN_HOME:-%{_bun_home}}" ; export BUN_HOME ; \
BUN_INSTALL_CACHE_DIR="${BUN_INSTALL_CACHE_DIR:-%{_bun_cache_dir}}" ; export BUN_INSTALL_CACHE_DIR \
BUN_RUNTIME_TRANSPILER_CACHE_PATH="${BUN_RUNTIME_TRANSPILER_CACHE_PATH:-%{_bun_cache_dir}}" ; export BUN_RUNTIME_TRANSPILER_CACHE_PATH ; \
DENO_DIR="${DENO_DIR:-%{_deno_dir}}" ; export DENO_DIR ; \
DENO_INSTALL_ROOT="${DENO_INSTALL_ROOT:-%{_deno_install_root}}" ; export DENO_INSTALL_ROOT ; \
DENO_NO_UPDATE_CHECK="${DENO_NO_UPDATE_CHECK:-1}" ; export DENO_NO_UPDATE_CHECK ; \
DENO_JOBS="${DENO_JOBS:-${RPM_BUILD_NCPUS}}" ; export DENO_JOBS ; \
PNPM_HOME="${PNPM_HOME:-%{_pnpm_home}}" ; export PNPM_HOME ; \
YARN_CACHE_FOLDER="${YARN_CACHE_FOLDER:-%{_yarn_cache_dir}}" ; export YARN_CACHE_FOLDER ; \
NPM_OPTS="${NPM_OPTS:-%{npm_config_opts} }" ; export NPM_OPTS ; \
BUN_OPTS="${BUN_OPTS:-%{bun_config_opts} }" ; export BUN_OPTS ; \
YARN_OPTS="${YARN_OPTS:-%{yarn_config_opts} }" ; export YARN_OPTS

This ensures the environment variables are explicitly exported and therefor are more likely to be picked up by all shell processes. It also creates environment variables called $NPM_OPTS, $BUN_OPTS, and $YARN_OPTS, which can be passed to NPM in lieu of the macros %{npm_config_opts}, %{bun_config_opts}, and %{yarn_config_opts}, respectively, to force our config if necessary.

This should only be needed in the event you are using %__npx, %__pnpx, %__bunx, %__dx, or %__yarn_dlx.

Nim

These macros assist with building Nim (opens in a new tab) projects. Currently atlas is not directly supported by the macros, but you can run it directly in %build:

%build
atlas init
atlas rep atlas.lock
%nim_c src/my_project

%nim_prep

Set up build environment with required packages via nimble setup.

This also adds the configuration for enabling mold automatically if found in the build environment.

%nim_build (or %nim_c)

Builds a Nim package. Requires an argument to src/pkgname.

Note that this does not invoke nimble. All dependencies SHOULD be ready before %build.

%nim_tflags

C compiler flags used in %nim_c.

%nim_lflags

Linker flags used in %nim_c.

Rust

These macros assist with building Rust (opens in a new tab) projects.

%cargo_prep_online

Enables internet access for %cargo_prep. Replaces %cargo_prep in %prep.

%cargo_license_online

Enables internet access for %cargo_license. Replaces %cargo_license in %build.

%cargo_license_summary_online

Enables internet access for %cargo_license_summary. Replaces %cargo_license_summary in %build.

%cargo_vendor_manifest_online

Enables internet access for %cargo_vendor_manifest_online. Replaces %cargo_vendor_manifest in %build.

%crate_install_bin

Used to install crates that build as single binary. Can be used instead of %cargo_install when this (opens in a new tab) is applicable.

%rustup_nightly

Used in the %prep section for nightly rustc/cargo from rustup.

Subpackages

These macros assist with packages that require certain subpackage types. For example, some packages will build application and library files. Using %pkg_devel_files will greatly help you in making the library files (-devel) subpackage. More information on subpackages can be found on the Fedora Packaging Guidelines (opens in a new tab).

%files_libs

This macro creates library subpackages and installs the library files. This is only for use in the %pkg_devel_files macro.

%pkg_completion

This macro creates shell completion subpackages and installs the shell completion files. This macro SHOULD be used if your package provides shell completion files. Use the below flags according to the shell completion files your package uses:

-B: bash (but the completion file doesn't have `.bash` extension)
-b: bash
-e: elvish
-f: fish
-N: nushell
-z: zsh

For specifying the name (the default will be your %name) of the shell completion subpackages (if needed):

-n pkgname

Can also pass cmd1, etc. as the commands the completion files are for.

Example using all flags:

%pkg_completion -BbefNz -n pkgname cmd1 cmd2 ...

A good example spec that uses this macro is yadm (opens in a new tab). This spec creates these packages:

yadm-x.x.x-x.fcxx.noarch.rpm - contains all core package files.
yadm-bash-completion-x.x.x-x.fcxx.noarch.rpm - contains `/usr/share/bash-completion/completions/yadm`
yadm-fish-completion-x.x.x-x.fcxx.noarch.rpm - contains `/usr/share/fish/vendor_completions.d/yadm.fish`
yadm-zsh-completion-x.x.x-x.fcxx.noarch.rpm - contains `/usr/share/zsh/site-functions/_yadm`

%pkg_devel_files

Set the summary & description, then find development files and install them to a subpackages %files. SHOULD be used in place of manually creating -devel subpackages.

For example:

%package devel
# generates Summary:, %description devel and the file lists
# -F to omit %files
# -n <pkgname>: name of the devel package
# -N <mainpkg>: name of the main package
%pkg_devel_files

%pkg_static_files

Set the summary & description, then find static libraries. SHOULD be used in place of manually creating -static subpackages.

For example:

%package static
# -n <pkgname>: name of the static package
# -N <mainpkg>: name of the main package
%pkg_static_files

%pkg_libs_files

Set the summary & description, then find dynamic library files (will be placed as %_libdir/*.so.*). SHOULD be used in place of manually creating -libs subpackages.

For example:

%package libs
# -n <pkgname>: name of the static package
# -N <mainpkg>: name of the main package
%pkg_static_files

Zig

These macros assist with building Zig projects.

%zig_build_target

Build Zig projects with a specified architecture and build mode.

Available flags:

• -c <?argument>: Used to set a specific CPU (micro)architecture to build for. If no argument is supplied, it will fall back to the %{_target_cpu} set by the build. You MUST specify a CPU architecture manually in cases where Zig's architecture format and RPM's do not match (e.g., aarch64).
  • SHOULD ONLY be used in projects that would not perform correctly when built for baseline.
  • For more information on x86_64 microarchitectures, see here (opens in a new tab).
• -r <argument>: Used to set the release/build mode (opens in a new tab). Accepted arguments are fast, small, safe, and slow.
  • SHOULD be used if a project would have performance issues if built for safe (what Fedora sets by default).
• -s: used to allow the project to link statically.
  • SHOULD ONLY be used if a project either has no dependencies to link, OR dependencies from the repos either aren't present or are incompatible versions.
  • You SHOULD still dynamically link compatible dependencies using -fsys=pkgname.

Example:

%build
%{zig_build_target -r fast -cx86_64_v2} \
  -Demit-docs

More information can be found on our Zig packaging guidelines.

Miscellaneous

General macros that do not fit into a specific category.

%evr

Used for declaring how a package interacts with others, such as, in a Requires: or Obsoletes: tag. For example, Requires: %{name} = %evr. Expands to: %{?epoch:%{epoch}:}%{version}-%{release}. Real package examples:

Requires: example:

BuildRequires:  pkgconfig(pkgconf)
BuildRequires:  pkgconfig(zlib)
BuildRequires:  pkgconfig(openssl)
BuildRequires:  pkgconfig(libarchive) >= 3.3.3
Requires:       %name-lib = %evr

Recommends: example:

Name:           rnote
License:        GPL-3.0
Recommends:     rnote-cli = %evr

Provides: example:

%package devel
Summary:        Development files for %{name}
Requires:       %{name}%{?_isa} = %{version}-%{release}
Provides:		%realname-devel = %evr
Conflicts:		%realname-devel

%git_clone

Downloads the source code via git clone, and passes useful (in this situation) flags such as--depth 1, -q, --recursive-submodules, and -j${RPM_BUILD_NCPUS}. A git URL and a %version or %commit MAY be passed to this macro. Below is an example of how a spec that tracks version tages from a GitHub repo, and needs to git clone the source could handle this:

Version:        0.8.0
---
URL:            https://github.com/ethangreen-dev/lovely-injector
---
%prep
%git_clone %{url} v%{version}

Below is an example of how a spec that tracks the latest commit from a GitHub repo, and needs to Git clone the source could handle this:

%global commit 9417838c91aab6088778089b9a3e8330bca53fbd
---
URL:           https://github.com/ad-oliviero/uwufetch
---
%prep
%git_clone %{url} %{commit}

%git_clone SHOULD only be used when the source tarballs provided by upstream does not include all required sources in the repository (e.g., if the build process expects a Git environment or the tarball doesn't contain submodules).

%go_task

Expands to: go-task --parallel --concurrency %{?_smp_build_ncpus} --verbose --yes SHOULD be used in place of go-task if using Go Task.

Unused in Spec Files

These macros are ONLY used by other macros in their expansion processes, as programmed here (opens in a new tab). These are documented ONLY for development and completion sake.

%__anda_develfiles

Expands to: %_anda_srpm_macros_dir/find-develinfo.sh %buildroot > anda-develfiles.list Used as a macro within %pkg_devel_files.

%__anda_libsfiles

Expands to: %_anda_srpm_macros_dir/find-libsinfo.sh %buildroot > anda-libsfiles.list Used as a macro within %pkg_libs_files.

%_anda_srpm_macros_dir

Expands to: /usr/libexec/anda-srpm-macros Anda directory for scripts such as find-develinfo.sh used by %__anda_develfiles, which is used in %pkg_devel_files.

%__anda_staticfiles

Expands to: %_anda_srpm_macros_dir/find-staticinfo.sh %buildroot > anda-staticfiles.list Creates anda-staticfiles.list file in %{buildroot} to be used by %pkg_static_files.

%desktop_file_args

This macro is created when using the -F option in %electron_install. It's used to pass the appropriate Exec arguments to desktop-file-install and has no other use.

%is_electron_bundled

Expands to %bcond bundled_electron %["%{name}" != "electron"] A functional macro that tells other macros if Electron is bundled or if the package being worked with is Electron itself. Used by %electronmeta and %electron_license.

%__tauri_common_opts

Common opts passed to Tauri. Used by macros which call Tauri.

%terra_rustflags

This macro simply appends the Mold linker arguments onto the %build_rustflags macro. It should not need to be manually used as %build_rustflags will be appended automatically when using %cargo_prep_online.

Footnotes