Add ability to build/install AUR packages without helper (use makepkg)

[moson-mo]

I'd like add to the ability to use plain makepkg next to an AUR-Helper for AUR package building & installation.

For the moment the following variable substitutions are available for the AurInstallCommand

{pkg} -> package name {pkgbase} -> package base {giturl} -> URL to package git repo in AUR

There is some rudimentary shell-script as some wrapper on top of makepkg to build and install a package with the following expression configured for AurInstallCommand:

scripts/pacseek-install {pkgbase} {pkg} {giturl}

It's basically just cloning the AUR git repo for the respective package and then executes makepkg to build and pacman -U... to install it.

I'm happy for any ideas for improvement and contributions on that matter (my shell scripting knowledge is extremely limited 😉 )

[rhaakoth]

Saw your post on EOS, and stopped by to see what was going on. If your scripting is extremely limited I am a novice, so take the following as such.

Line 4-7 Are you accounting for a user finding your wrapper script and running it outside of pacseek? -Otherwise I would think you already have controlled what is being passed

Line 17 You could shorten this to if [ "${clean,,}" == "y" ]; then -As you are only worried about Y/y, it isn't saving much compared to A/a, B/b, C/c, etc...maybe this is writer bias :)

Line 37 Could you change it to makepkg -rsfi and remove 39-47? -might be misreading what that last block of code is doing, but -i does install/upgrade using pacman

Not sure if any of this will help.

[moson-mo]

Hi @rhaakoth

thanks for your input.

Line 4-7 Are you accounting for a user finding your wrapper script and running it outside of pacseek? -Otherwise I would think you already have controlled what is being passed

yeah, more or less. It's still up to user to define the command calling the script, so I just want to avoid any mistakes and have at least somewhat of an input validation before things kick off. Could probably make sense to have named arguments instead (like using getopts or so)

You could shorten this to if [ "${clean,,}" == "y" ]; then

Ok, thanks for the hint.

Could you change it to makepkg -rsfi and remove 39-47?

The reason not to install with makepkg is account for split-packages where one PKGBUILD has a definition for multiple packages. Some time ago makepkg had a --pkg flag that allowed you to specify the package, but that was removed at some point. That's why we get a list of packages that are being built and only install the desired one.

[rhaakoth]

Hi @moson-mo

You are welcome.

yeah, more or less

I was stuck at the current paradigm pacseek uses of search and here are your choices, this now sounds like you are allowing free input for what a user wants. Will a new user know that pkgbase and pkgname could be different? Or what pkgbase even is? Sorry if my visualization sucks, I don't know what A is, but am trying to help with B.

PKGBUILD has a definition for multiple packages

I have learned something new for today and can go back to bed. I had not run into that situation, so thank you for explaining it.

[moson-mo]

this now sounds like you are allowing free input for what a user wants.

Yes, the commands that are executed for package installation / removal / upgrade are completely configurable.

Will a new user know that pkgbase and pkgname could be different? Or what pkgbase even is?

Well, ideally yes 😉 However, nobody forces one to modify the default commands (utilizing yay).
So the user does need to know this at all. I just want to offer a possibility of configuring more sophisticated commands.
Some users might want to use them. It's all optional 😀

[rhaakoth]

commands that are executed for package installation / removal / upgrade

Well that is embarrassing, it just clicked where "A" is (ref prev post), as I change that to paru.

With that to think on, I will try to make any further input more useful, and thanks for the great utility!