pacaur proceeds to install without previewing PKGBUILD if the new PKGBUILD has already been fetched

ahmedalsudani commented 6 years ago

Version

pacaur 4.7.10

Description

Scenarios

package is not installed If you run pacaur -S package, pacaur asks if you want to see the PKGBUILD file.
package is "installed" (i.e. its build files are in ~/.cache/pacaur/) but build files are out of date If you run pacaur -S package, pacaur asks if you want to see the PKGBUILD diff.
package is "installed" (i.e. its build files are in ~/.cache/pacaur/) but build files are up to date If you run pacaur -S package, pacaur prints package build files are up-to-date -- skipping and proceeds

This is either a bug or not a bug depending on how you look at it, but I think the current behaviour is not ideal.

Mechanism

From a quick look at the source code, it seems like pacaur puts the previous commit hash in .git/HEAD.prev and prints the diff between that commit and current HEAD.

I have not looked at the code carefully enough to have a good picture of when that happens, but my guess is that the HEAD.prev file is updated before pulling the newest revision.

Proposed Change

Change what we store in HEAD.prev or add a new file (something like HEAD.installed) which is only updated after the package is actually installed. That would make it possible to show the user the actual changes between what they have on their machine and the new version.

Notes

This has been my biggest (maybe only) annoyance when using pacaur.

Sometimes I will initiate pacaur -Syu and cancel for one reason or another. Next time I run pacaur -Syu, I am not prompted to view the PKGBUILD files. This behaviour scares me.

I am willing to make this change and create a PR for it, but I first want to know if you agree that what I'm proposing is a good idea that should go into pacaur.

rmarquis commented 6 years ago

Working as designed. The rational is that pacaur won't automatically prompt for PKGBUILD changes you already have checked, but you can always force a review by passing the -e flag.

I'd add here that you might want to investigate the reason you cancel the process after the main prompt. See also #773.

ahmedalsudani commented 6 years ago

Fair enough.

I'd add here that you might want to investigate the reason you cancel the process after the main prompt.

Cancelling is common behaviour, and there are many reasons to cancel and proceed later. Just because you have a different workflow doesn't mean all of humanity should try to emulate you.

rmarquis commented 6 years ago

My question was actually genuine, in the sense that the main prompt displays all required information. I'm not sure why someone would agree to it and then decide not to proceed just a few seconds later.

But since some people seems to believe I have to code with all humanity workflow in mind, I'll gently remind them that no, I don't have to.

mrnamwen commented 6 years ago

Sorry to bring up a closed topic, but I figured I may give a usecase where such a thing may need to happen.

I was just compiling wine-git, when I realised I had accidentally not corrected the PKGBUILD to use multiple cores. I had to cancel the build and instruct pacaur to open the PKGBUILD so I could insert the relevant parameters to build with all of my cores.

rmarquis commented 6 years ago

Sorry to bring up a closed topic

No worries, this is exactly the reason closed issues aren't locked.

Your user case is somewhat a bit different: in that case, you'll have reviewed the PKGBUILD to ensure it doesn't have a security issue already.

But I guess that PKGBUILD diff viewing only happens the first time it is encountered by default isn't clear enough (currently: the diff option only displays the difference since last build). Would an additional note section covering the need to use --edit explicitly be enough here?

On a side note... you probably should configure the MAKEFLAGS directive of makepkg.conf (f.e. with -j4), instead of modifying the PKGBUILD separately.

mrnamwen commented 6 years ago

you probably should configure the MAKEFLAGS directive of makepkg.conf (f.e. with -j4), instead of modifying the PKGBUILD separately.

Thanks for the tip. I'm used to compiling builds from git but not entirely used to how the ABS completely functions yet.

As for that note, it would definitely help to make it clear a user could pass that argument to modify a PKGBUILD again.

rmarquis / pacaur