makechrootpkg: fix an infinite loop when installing package with -I

[dbermond]

When installing with the -I option a package which in turn has a dependency with multiple providers, makechrootpkg enters in an infinite loop. This happens because we are using the pacman -U command piped with yes y. The yes y command outputs only y lines, but when installing a dependency package with multiple providers pacman expects a number as the input. Being such, makechrootpkg outputs this endlessly:

Enter a number (default=1): error: invalid number: y

Using the pacman --noconfirm option without piping yes y fixes the issue.

There are other ways to fix it, like piping while :; do printf "y\n1\n"; done instead of yes y, but simply using --noconfirm looks simpler and better.

Example package to reproduce: flutter^AUR (depends on android-sdk^AUR). When executing extra-x86_64-build -- -I /path/to/android-sdk-26.1.1-1-x86_64.pkg.tar.zst, it will enter in an infinite loop because java-environment (dependency of android-sdk^AUR that is being installed with -I) has multiple providers.

[anthraxx]

This unfortunately isn't as easy as that. Its a bit back and forth play here as this would break other functionality.
see the reasoning for this change in the following commit: b7893a2

[dbermond]

@anthraxx Thank you for the reply.

Instead of using --noconfirm (which seems to be the problem on the pointed commit), would another method be acceptable as I already mentioned on the first post? Like using while :; do printf "y\n1\n"; done instead of yes y.

[eli-schwartz]

NACK.

If you have multiple providers in your dependency tree for an -I package, you can add e.g. -I /path/to/jdk-openjdk-15.0.1.u9-1-x86_64.pkg.tar.zst which means you can, ultimately, resolve your -I requests. However, if you used -I /path/to/pacman-git-6.0.0alpha1.r64.gab549c84-1-x86_64.pkg.tar.zst then you're completely unable to resolve it if you use --noconfirm, end of story.

Given a choice between two approaches:

• one which permits you to do 2 things, one of which is unintuitive and wordy
• one which permits you to do 1 thing, and completely prevents the other thing

I believe the former is a better choice.

...

No, alternately sending "y" and "1" doesn't actually work, it merely causes [Y/n] dialogs as well as [y/N] dialogs to abort when reading "1".

[dbermond]

@eli-schwartz Thank you for the reply and explanation.

Looks like this is a wontfix type of issue then.

I'll close this pull request. Thank you all.