Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Implement an alternate "slow" workflow mode (instead of piping yes output) for advanced compatibility #73

Closed
rmarquis opened this Issue Apr 30, 2012 · 3 comments

Comments

Projects
None yet
2 participants
Owner

rmarquis commented Apr 30, 2012

Following issue #71: When dealing with kernel-ck package, and using nconfig (maybe also menuconfig, xconfig, gconfig) pacaur fails as the yes utility interfers with nconfig.

A workaround might be:

  • check which package does not work with yes pipe (known to fail: kernel-ck with optional nconfig customization)
  • automatically switch to a --noconfirm mode (for that package only)
  • check and solve packages conflict beforehand without the yes utility (for that package only)
Contributor

lucy commented May 4, 2012

This issue also appears when trying to install AUR packages that depend on java without having a java runtime installed. When pacman/makepkg asks which java runtime I want to install, this happens:

~ > p minecraft                                         
:: Package(s) minecraft not found in repositories, trying AUR...
:: no results found for minecraft
~ > p minecraft
:: Package(s) minecraft not found in repositories, trying AUR...
:: ca-certificates-java is available in extra
:: jre7-openjdk is available in extra
:: jre7-openjdk-headless is available in extra
:: openal is available in extra
:: rhino is available in extra

AUR Targets (1): minecraft

Proceed with installation? [Y/n] y
:: Edit minecraft PKGBUILD? [Y/n] n
:: View minecraft .install script? [Y/n] n
:: Building minecraft package...
==> Making package: minecraft latest-17 (Fri May  4 21:36:09 CEST 2012)
==> Checking runtime dependencies...
==> Installing missing dependencies...
:: There are 2 providers available for java-runtime:
:: Repository extra
   1) jre7-openjdk  2) openjdk6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

^C
Interrupt signal received


==> ERROR: Aborted by user! Exiting...

~ > 

And I'm unable to choose 1 or 2.

Owner

rmarquis commented May 6, 2012

Yes, the difficulty here is knowing which packages needs manual interaction. I guess the only way to "fix" that issue is to add a new option to disable fast workflow (ie, --manual).

Edit: No, it seems that is pacman itself that is asking what to install here. Not exactly the same issue as this is not dependent of the PKGBUILD content. Thanks for reporting, as always.
Tracking this new issue in #77.

Owner

rmarquis commented Jun 15, 2012

This feature is going nowhere, as there are no way to detect properly which PKGBUILD would need to be treated in a "slow" mode, and each buggy packages needs to be treated on a per-case basis.
Also, I guess the following does the trick:

pacaur -Syu --ignore linux-ck
[[ -n $(cower -u | grep "linux-ck") ]] && cower -d linux-ck && cd /path/to/pkgbuild && makepkg -sfi

In a nutshell, I'm going to close this feature as "wontfix" and above case should be handled with cower (as this is originally intended when tinkering pkgbuild). Please reopen if someone has a brillant, simple and working workaround.

@rmarquis rmarquis closed this Jun 15, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment