How to automate user interaction in xbps-src template

[gc-user]

I created a template for local use which when run via xbpr-src at one point halts the so_install process to ask for a license agreement.
I was wondering if I could automate the user interaction by adding some lines to the template.

I would be able to work with a patch, but that would not be my preferred method.

[classabbyamp]

yes(1) perhaps

[gc-user]

Thanks for the hint.
I tried different variations, but for some reason I can't make it work. The best I get is "Permission denied". Even though I found one (1) package (python3-GitPython) that uses the exact same line
yes | ./path/to/script
without any error.

But I was at least able to use sed -i to "hard-code" the "yes" into the file with the command. So, it's still a patch (in a way) but without an actual patch (file).

[kinqsradio]

"Permission denied" there is most likely just the installer not having the executable bit after it's extracted (GitPython's script is executable in its repo, which is why the same line works there). You can either run it through the shell so it doesn't need +x:

yes | sh ./installer.sh

or chmod +x ./installer.sh right before the yes | line in the same function. Also keep in mind the phase runs from wrksrc (or build_wrksrc if you set it), so the ./ path is relative to that.

[gc-user]

Thanks for the tip!
It works - somewhat.

Yes, the .sh file wasn't executable after extraction.

Both options solve that issue.

Now the "previous" issue "is back".
If I use yes - before or after the command - the build process would not execute the script but type new lines with "y" forever - until manually stopped.
If I use echo "yes"- before or after the command - the build process execute the script but the yes would not be injected and so the process stops to wait for user intervention.

That's a bit weird as the latter is was I essentially did with the variant where the file that naturally calls the script gets changed to having " | echo "yes" added - and that works just as intended.

But this also might be tied to the particular package. Because if I do the "auto-accepting" in do_build the build process stops at the install step to ask for user intervention, if I put it in do_install the build process stops at the build step and waits for the "yes". If I put it in twice, once in do_build and once in do_install the build process stops after the install step claiming "PKGDESTDIR is empty and metapackage != yes".

My intervention via the template would probably have to be "conditional" which is beyond my (current) capabilities, which is why I continue to use the "brute force" method of changing the content of the file that executes the scipt.

But I still learned a few more things, so this exercise wasn't totally useless.

Thanks for the help!

[gc-user]

As it turns out, there's a PR that got stale and closed which addresses the package. It, too, auto-accepts the license-agreement but in a different way. As that template was created by someone much more capable than myself, I will use that one going forward, even though mine works, too.