[pacman-dev] inside PKGBUILD customizable makepkg PURGE_TARGETS

Ciprian Dorin, Craciun ciprian.craciun at gmail.com
Wed Dec 2 23:56:05 EST 2009

On Thu, Dec 3, 2009 at 2:39 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Wed, Dec 2, 2009 at 3:48 PM, Allan McRae <allan at archlinux.org> wrote:
>> Ciprian Dorin, Craciun wrote:
>>>    Hello all!
>>>    Again I have a proposal to enhance makepkg PURGE_TARGETS handling.
>>>    I think that enabling customizing PURGE_TARGETS inside PKGBUILD
>>> would be a benefit in the following context:
>> Without checking, I would have thought that exporting "PURGE_TRAGETS=..."
>> within a package function would just work.  I guess the old value would not
>> be restored afterwards though.
> This seems like complete overkill for makepkg to support. I'm -1 on this.

     What overkill? Really? It's a 3 or 4-line update:

~~~~ instead of this:
        if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then
                msg2 "$(gettext "Purging other files...")"
~~~~ we'll have this:
+        local purge_targets=( "${pkg_purge_targets[@]:-${PURGE_TARGETS[@]}}" )
+        eval 'purge_targets=(
"${'"${pkgname}"'_purge_targets[@]:-${purge_targets[@]}" )'
+        if [ "$(check_option purge)" = "y" -a -n "${purge_targets[*]}" ]; then
 -       if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then
                msg2 "$(gettext "Purging other files...")"
~~~~ and we have to replace `PURGE_TARGETS` with `purge_targets`
somewhare below in 2 places.

> If upstream builds can't get their act together and provide individual
> make commands, file a issue upstream. If that doesn't work, then
> PURGE_TARGETS is really no more than a

    Have I mentioned that even pacman doesn't support these make commands?

> for file in glob_exp; do
>    rm -f file
> done
> which is really just a one-liner in a PKGBUILD anyway. Why complicate
> the matter?

    Actually it's a 3-liner per `something_package` function, in every
PKGBUILD, instead of a true 1-liner in every function in every

> -Dan

    Guys, as developers of makepkg, you really have something against
extensions that would allow writing simpler or more versatile

    For example, below is one of my PKGBUILDS, that uses what I call a
"template", which allows me to abstract away patching, calling
configure, and make. And in order to support this split of packages,
all I have to do is update my `configure+make+make-install` script to
understand this, and just put `pkgname=( isync-bin isync-doc )`.
(Unfortunately this doesn't have a lib or dev).

    My `configure+make+make-install` just implements `build` and
`package` functions that use the variables defined in the PKGBUILD,
with some sensible defaults. (I think this resembles somehow GoboLinux

. "${pkgbuild_tools_root}/configure+make+make-install"

pkgname=( isync )

		openssl db
		gcc binutils glibc
		make coreutils bash
		sed grep patch



		-ldb -lpthread



    But as I said, no problem, I'll just hack my own makepkg that
understands something similar with PKGBUILDS, and extended with these


More information about the pacman-dev mailing list