Feature request: Customizepkg

[stefanhusmann]

What about supporting customizepkg?

It is a nice tool to let you automtize changing PKGBUILDs on the fly. It is usefull for some circumstance, e.g. if you want another download mirror as the AUR default provides ore change default configure options.

In fact there are several flavours of customizepkg in the AUR, but they all use the same interface to the user or to aur helpers.

[Morganamilo]

I had never heard of this before, giving a quick look over it seems like you just cd into the pkgbuild dir and run customizepkg. It then figures out everything based on its config.

So all you'd need to do to support this is run customizepkg after a pkgbuild download/update?

[Jguer]

Seems so, if it's only that I don't see an issue with adding such a flag.

[stefanhusmann]

Yes, it is only that. customizepkg -m, to be exact.

[Morganamilo]

If we were to support this I was thinking of some sort of post download script that Yay could call. Something generic that would work with this program but could also be useful for other things.

How much do you expect to be able to change with this program though? Yay is designed for batch actions, ask questions first then do stuff. It also gets info from the RPC rather than pkgbuilds. If you were to change the dependencies then Yay won't check these because it's already passed the dep resolving stage and it uses the RPC for dependencies anyway. If you change the pkgname then Yay won't know because it got the name via the RPC and won't see the change.

The readme said it integrates with Yaourt, I assume it's a lot easier to implement with this type of program. Yaourt handles one package at a time and I'm not even sure if it uses the RPC.

I'm not saying you can't use customizepkg with Yay its use will be limited. It's possible to fix these limitations though just very tedious.

[stefanhusmann]

I cannot imagine what comes into people's minds, but if they change depepndencies in the PKGBUILD they should know what they are doing. They can also change dependencies with their texteditor. I see no fundamental difference here.

I use customizepkg for changing a download mirror, or renaming a version number only tarball to one including the package name and the like, so merely for little things that make me GRRR .

[DL6AKU]

+1 for customizepkg. I use customizepkg (actually customizepkg-patching) to modify the linux-ck PKGBUILD to enable xconfig and to enable some extra options for the kernel build.

[ava1ar]

Will be very handy and should not be difficult to implement. pakku implemented it via the PreBuildCommand support.

[kageurufu]

For now, you can hackily do this with a custom makepkg command, I placed the following script at ~/.local/bin/customize-makepkg

#!/bin/sh

if [[ -e "$HOME/.customizepkg/$(basename $(pwd))" ]]; then
  customizepkg --modify >&2
fi

exec makepkg ${@}

Then ran yay --save --makepkg $HOME/.local/bin/customize-makepkg

Its not the cleanest, but it works for now

[surskitt]

@kageurufu I tried your script, but it ends up doing four passes of customizepkg.

[Jguer]

yay runs makepkg more than once and for various reason. For that script to work you need to only execute customizepkg if the ${@} contains maybe: -cf and --noconfirm. This should make sure it only runs once

install.go : 964

args := []string{"-cf", "--noconfirm", "--noextract", "--noprepare", "--holdver"}
if incompatible.get(pkg) {
  args = append(args, "--ignorearch")
}

err := show(passToMakepkg(dir, args...))

[monyarm]

I tried that script and now i get Error downloading sources: when i try installing something with yay

[kageurufu]

So, i've experimented with a few things, but found that just adding a flag to the PKGBUILD works the best, and is going to be the most resilient against changes to yay. Heres my current version

#!/bin/sh

if ! grep -s "## $0 ##" PKGBUILD >/dev/null && \
   [[ -e "$HOME/.customizepkg/$(basename $(pwd))" ]]; then
  customizepkg --modify >&2

  echo "" >> PKGBUILD
  echo "## $0 ##" >> PKGBUILD
fi

exec makepkg ${@}

@monyarm did you put the script somewhere, make it executable, and use the right path in your yay command?

[monyarm]

Ya, that's precisely what I did.

On Fri, 30 Nov 2018, 19:25 Frank Tackitt <[email protected] wrote:

So, i've experimented with a few things, but found that just adding a flag to the PKGBUILD works the best, and is going to be the most resilient against changes to yay. Heres my current version

#!/bin/sh

if ! grep -s "## $0 ##" PKGBUILD >/dev/null &&
[[ -e "$HOME/.customizepkg/$(basename $(pwd))" ]]; then customizepkg --modify >&2

echo "" >> PKGBUILD echo "## $0 ##" >> PKGBUILD fi

exec makepkg ${@}

@monyarm https://github.com/monyarm did you put the script somewhere, make it executable, and use the right path in your yay command?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Jguer/yay/issues/336#issuecomment-443276676, or mute the thread https://github.com/notifications/unsubscribe-auth/AC50qjVuVES0qZdvtdWsgb6AqZskMiW7ks5u0Wn7gaJpZM4TLCPi .

[AdrienLemaire]

@kageurufu can you give more details on how to get this working?

I created an executable script in my ~/bin/ dir (which is in my PATH) with your code, and also mkdir the ~/.customizepkg/ dir.

I then downloaded the PKGBUILD with

$ yay -G task
$ mv task ~/customizepkg/

I downloaded the patch and generated the sha256sum, then modified the PKGBUILD

$ cd ~/.customizepkg/task/
$ diff PKGBUILD*
6a7
> # PATCH: https://github.com/GothenburgBitFactory/taskwarrior/files/1755622/TW-1778_patch.diff.txt
18,19c19,32
< source=("https://taskwarrior.org/download/$pkgname-$pkgver.tar.gz")
< sha256sums=('d87bcee58106eb8a79b850e9abc153d98b79e00d50eade0d63917154984f2a15')
---
> source=(
>     "https://taskwarrior.org/download/$pkgname-$pkgver.tar.gz",
>     "https://github.com/GothenburgBitFactory/taskwarrior/files/1755622/TW-1778_patch.diff.txt"
> )
> 
> sha256sums=(
>     'd87bcee58106eb8a79b850e9abc153d98b79e00d50eade0d63917154984f2a15',
>     'de08f9475560619f727c3c7a342504e60e3b033decfc685de4b8940a7641495b'
> )
> 
> prepare() {
>     cd $pkgname-$pkgver
>     patch --forward --strip=1 --input="${srcdir}/TW-1778_patch.diff.txt"
> }

Finally I tried executing your command

$ yay --save --makepkg $HOME/bin/customize-makepkg task

But the patch hasn't been applied.

[kageurufu]

@Fandekasp customizepkg doesn't work on already modified PKGBUILDs or .patch files natively. You write a series of changes to apply to the PKGBUILD to add the patch to sources, sha256sums, and adding the prepare() block.

Heres a decent guide on how to use customizepkg, including applying .patch files: https://www.supertechcrew.com/customizing-aur-arch-package-with-customizepkg/

[monyarm]

So i tried the following:

Copying your script to ~/.local/bin Creating the .customizepkg folder and putting a text file called hello in there, the file contains 'replace#pkgver#2.10#3.3' But i get "/home/monyarm/.local/bin/custpkg: line 2: [[: command not found" when i try to install it

[monyarm]

So, i managed to fix it by doing the following: Changing #!/bin/sh to #!/bin/bash Removing the
Making sure everything is on it's own line, cause some of the linebreaks didn't copy over for some reason.

[DocMAX]

so is yay supporting Customizepkg or not? for me nothing is done with the files in /etc/customizepkg.d!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[HaleTom]

Calm down please stale bot!

[Zulgrib]

Official support for this would be greatly appreciated.

[Maik93]

Sorry for necrodumping, but what does --save should do? It is not present anymore in yay v10.1.2.

[shiraneyo]

Clear +1 from me, official support for this would be great.

In the meantime, I'm overriding makepkg by creating the below script under /usr/local/bin/makepkg. This approach has the advantage of not needing to touch the yay build parameters for the customized packages, so that yay -Syyu --noconfirm works fine.

#!/usr/bin/env bash
# makepkg wrapper that calls customizepkg first
set -euf -o pipefail +o history

CURRENT_DIR_PATH="$(readlink -f "$(realpath -e "$(pwd)")")"
GLOBAL_CONF_DIR_PATH='/etc/customizepkg.d'
USER_CONF_DIR_PATH="${HOME}/.customizepkg"

pkgbuild_path="${CURRENT_DIR_PATH}/PKGBUILD"
pkgbuild_copy_path="${pkgbuild_path}.original"

function is_readable_file {
  local file_path="${1:-''}"
  local ret=1
  if [[ (-n "$file_path") && (-f "$file_path") && (-r "$file_path") ]];then
    ret=0
  fi
  return $ret
}

if  is_readable_file "$pkgbuild_path" &&
    ! is_readable_file "$pkgbuild_copy_path";then
  source "$pkgbuild_path"
  if [[ -n "${pkgname:-''}" ]];then
    global_conf_path="${GLOBAL_CONF_DIR_PATH}/${pkgname}"
    user_conf_path="${USER_CONF_DIR_PATH}/${pkgname}"
    if  is_readable_file "$global_conf_path" ||
        is_readable_file "$user_conf_path";then
      customizepkg --modify
    fi
  fi
fi

exec /usr/bin/makepkg ${@}

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SwooshyCueb]

go away stalebot

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Jguer]

not stale

[HalJordan]

The workaround from @shiraneyo is great, but it'd be nice if something(even if it's just adding in what shiraneyo has) could be added to this.

[LevitatingBusinessMan]

@shiraneyo Your workaround seems to have an issue. Many packages are giving me an error PKGBUILD: line 27: CARCH: unbound variable.

Along with other errors of unbound variables.

[icedream]

The workaround scripts causes the following side effects:

• The above mentioned unbound variable issue happens for variables supposed to be pre-set such as CARCH due to the fact that the script needs to extract the PKGBUILD's pkgname variable by sourcing it itself. The script could set these variables itself but that easily becomes complicated to maintain for a hack.
• Changes by customizepkg to depends or other variables that yay needs to parse up front won't have their intended effect: makepkg will complain about missing dependencies that yay should have installed but didn't because customizepkg happened too late. This can't exactly be easily solved with a hack.