Skip to content

Latest commit

 

History

History
101 lines (54 loc) · 6.9 KB

makepkg-expanded.md

File metadata and controls

101 lines (54 loc) · 6.9 KB
Raw

makepkg-expanded(1) -- process template expanded PKGBUILDs

SYNOPSIS

makepkg-expanded [ options ]

DESCRIPTION

This is a wrapper around makepkg-template(1) and makepkg(1) that can be used to build and distribute packages without touching templates in the original PKGBUILD.

It does so by expanding the templates in a temporary file besides the original which is then cleaned and used for further processing. This leaves the template markers as they are while keeping the AUR free from template relics.

OPTIONS

  • -h: Shows a summary of the options.

  • -p buildscript: Select an alternative file to process instead of PKGBUILD.

    Unlike makepkg, files outside the current working directory will not be rejected. Instead, any processing will be done from within the directory the given file resides in.

    Also unlike makepkg, this option may be given multiple times to batch build many packages with the same settings. However, the next option may be even more fit for this purpose.

  • -a [pattern]: Select all files matching the given pattern from the current working directory and below.

    The pattern is passed to find(1) and thus may use wildcards supported there.

    If no pattern is given, it is assumed to be PKGBUILD.

  • -t dir: Specify a directory to look up templates in. These will be passed on to makepkg-template(1) as --template-dir options.

    If makepkg-template(1) supports it, this option may effectively be given multiple times. See [BUGS][] for details. As it is the case with makepkg-templates(1), the directory specified last will take precedence in case a template could be fetched from multiple of them.

    Without any -t, the system-wide default is used, which normally is /usr/share/makepkg-template. When makepkg-template is invoked from anywhere within a git(1) repository, it will also use templates from a makepkg-templates directory located in the root of the repository, if such exists. Note that an explicit statement of -t overwrites these defaults. So if they shall be mixed with more directories, they have to be specified explicitely.

  • -e suffix: Specifies a suffix to prepend to the name of the original build script to compose the file name to store the intermediate expanded content to. They will always end up in the same directory as the original.

    The default is .expanded, so without any options, the script actually processed will be called PKGBUILD.expanded.

  • -m: This option is passed to clean-templates(1) which is invoked immediately after template expansion to leave template markers and mode lines intact. Duplicate templates will still be removed.

    When the -l option is also specified, cleaning is skipped completely.

  • -d: Only remove mode lines and template markers instead when cleaning and leave duplicate templates untouched.

    This completely avoids clean-templates invocation and instead replaces it with sed, as mentioned in the clean-templates(1) manual page. When the -u option is also specified, cleaning is skipped completely.

  • -r command: Command to execute after expanding each PKGBUILD.

    The given snippet will be run through bash -c and receive the file names of the expanded and original PKGBUILD as its respective arguments. It will be run from the directory where the processed PKGBUILD resides in.

    If any execution yields an exit code other than 0, makepkg-expanded will abort instantly with the same exit code.

    If this option is given multiple times, all the given commands will be run on all expansion results in the sequence they were specified.

    The default command invokes makepkg(1) on the expanded PKGBUILD and then uses cp-pkgver(1) to propagate any version updated back to the original if the former completed successfully. This would be roughly equal to passing 'makepkg -p $1' and 'cp-pkgver $1 $2' with this option. To pass additional options, alter this expression to your liking. For example, passing 'aurbranch -p "$1" "${@/%/:}"' here instead would instead prepare a branch for distribution to the Arch User Repository.

    For the context of executing these commands, the bash special variable GLOBIGNORE is set to exclude the original and expanded build script, so that they both do not get captured while globbing. This is a safety measure to not accidentally include them in any argument list generated by expanding wild cards like * . To include them, they have to be explicitly specified. Files starting with a dot are also still considered hidden as usual. A GLOBIGNORE already set when executing makepkg-expanded will be taken into account. To exclude files ignored by git, it may be useful to filter the file list returned by the wildcard through "git ls-files -co --exclude-standard *".

    A command string exactly matching the pattern exec bash '<file>' "$@" with file containing only escaped single quotes ('\'') will short-ciruit the usual interpretation of the command string through the shell and be executed directly. The -R option composes exactly this format.

  • -R file: Specify a script to be executed on each expanded PKGBUILD. Its parameters are the same as given to the command string run through -r. This can be thought of as reading the string passed to -r from a file.

    Technically, it is the same as if -r exec bash '<file>' "$@" would have been passed, but using -R instead takes care of expanding the file name to be absolute beforehand, so that the same file is reached also when multiple PKGBUILDs are processed in different locations. It also allows makepkg-expanded to be used in a shebang expression starting a file containing the snippet code to be executed.

    It generates one command that will run in a dedicated bash instance and can be intermixed with more -r options.

  • -b: An alias for an improved version of the ubiquitous aurbranch invocation through -r.

    The exact command line composed will use the expanded PKGBUILD in place of the original, still taking into account changes to the original when suggesting a commit message.

EXIT STATUS

When the program exits with status 0, it is safe to assume that all PKGBUILDs were successfully processed. This means that all -E statements exited with code 0 or, in the absence of such, all packages were created.

When makepkg-template(1) fails on any PKGBUILD, the program immediatly halts passing through its exit code.

When the processing fails, the exit code of the code snippet is passed through. By default, failures in makepkg(1) are propagated while cp-pkver(1) may silently fail.

BUGS

This project was created by XZS d.f.fischer@web.de and lives at GitHub. Bugs can be filed in the tracker found there.

SEE ALSO

makepkg-template(1), makepkg(1), clean-templates(1), cp-pkver(1), bash(1).