I think that is the reason Dalto. Hence, my conflation of AUR and pacman questions in the update process, as it changes according to what I have installed and needs updating. It still doesn’t help me answer the questions 
I read them carefully … next time it comes up I will post it for comment before accepting.
Before using the AUR, it’s a really good thing to understand how packages are built on Arch.
The AUR is not a repository of packages, it is a repository of user submitted PKGBUILD files, which are shell scripts that are used to create packages. When you want to install something from the AUR, you download all the necessary files, build the package locally and then install it as a foreign (non-repo) package. Since you are building it yourself, this means you are responsible for what goes into it. Not understanding what’s going on can get you in trouble.
I understand what you’re asking about now. Do you want to clean build for instance? Read up on how to use yay and it’s manual which it should have somewhere. I usually keep build files and don’t clean build for instance.
It’s really up to you
If you have snapshots you can revert to, why would you keep old builds? Maybe they don’t use much storage.
how are snapshots related to old builds???
I think you’re highly confused here. I suggest you read these two pages in detail:
https://man.archlinux.org/man/pacman.8
Give an example of the terminal output you want our input on and we’ll try our best to answer…
I am referring to Btrfs Assistant restoring a snapshot of an old package.
Thanks for the document. I will study it in detail.
As Dalto pointed out it changed each time. I will post it the next time.
Frankly, I am surprised no one has raised this issue, when users run Welcome daily (at least I do). Not every update proposes all these package replacement/updates. But I will be sure to post the next one, and maybe others can do the same.
welcome usually calls yay (since we install it by default) for handling AUR packages
Most 
users get familiar with using yay while running
Reading yay man page which I’ve linked will help you a lot in this regard.
There should also be some discovery articles on AUR packages and yay. I suggest you read those.
Concreate example…
Remove make dependencies after install? (y/N)
What should I choose? why one over the other? Do I need the make dependencies after I have installed?
Can you link to documentation regarding what the choices with Diffs to show?
It is in the man page for yay.
This menu gives you the option to view diffs from build files before building.
Diffs are shown via git diff which uses less by default. This behaviour can be changed via git’s config, the $GIT_PAGER or $PAGER environment variables.
That being said, that seems pretty clear what to do just from reading the screen. Press the option you want. What isn’t clear from the text on the screen?
None - Shows you no diffs
All - Shows you diffs for all the packages
Abort - Stops the yay operation
Installed - Only show diffs for packages that installed
NotInstalled - Only show diffs for packages that aren’t installed.
Alternatively, enter the numbers for the packages you want to see diffs for.
PS. That information I shared is just from me reading your screenshot. I don’t have super secret knowledge or anything.
Well, that depends on if you want to remove the make dependencies or not. Nobody can really answer that for you.
The problem is probably not that you don’t know how to answer the question. It is probably that you don’t understand what “make dependencies” are. That documentation is in a few places. Let me grab you a link.
https://wiki.archlinux.org/title/PKGBUILD#makedepends
From the link:
packages that are only required to build the software.
Keep them installed if you want, remove them if you don’t.
That’s not me… 
Sp pkgbuild is where these questions are coming from, not AUR or pacman. Thank you for your patience with me.
pkgbuild is the Arch packaging format. All the packages from the repos or the AUR are assembled with makepkg by reading a PKGBUILD.
In the case of a repo package, someone has built it for you using the PKGBUILD. In the case of an AUR package, the PKGBUILD is downloaded to your machine and the AUR helper(yay in this case) uses makepkg to built it on your machine.
If you use AUR, you really should understand how a PKGBUILD works. It really isn’t hard if you don’t panic and read through it slowly.
It’s hard not to panic when you are forced to make a decision on the spot, without knowing the implications of the decisions.
That’s the advantage of having btrfs Assistant, I can always restore. Thanks for your guidance. The solution is obviously to read the links you gave me.
Thanks once again. I will leave this open a while longer, but I expect this is the SOLUTION.
I totally agree with you, the prompts from AUR are cryptic to me and I meant to read what that all means at some point but due to lack of time, never really dug into it. On the other hand, I don’t really install that many AUR packages. I always install the same. I tried to build some myself and read the scripts but still confused what which prompt is doing and even what is meant by diffs. I understand for example on GitHub diffs show adding/removing code lines when I commit and push. But not sure what diffs AUR is supposed to show me, and what option should be chosen when/which scenario.
I guess back to arch wiki when I find the time, but guide for dummies would be nice anyways.
So we are not alone.
Cryptic perfectly describes it.
I read the link on yay and did not teach me anything new.
But a deep dive in pkgbuild docs is on my list when i find time.
An AUR helper is a very useful tool because it checks for updates for foreign packages, so you don’t have to keep track of them manually. However, the automation provided by an AUR helper also obfuscates the package building process. So if you don’t know what is going on, and you use a tool that automates the process, of course it’s going to be cryptic!
That is why I so often repeat myself: you shouldn’t be using an AUR helper until you know how to build packages manually and have at least a basic understanding of how the packaging on Arch works. The AUR is not like a normal repo, it’s essentially a PKGBUILD sharing website. If you don’t know what a PKGBUILD is, you really shouldn’t be using the AUR.
That’s the problem with AUR helpers: they allow people who do not understand how the AUR works to install software from the AUR, thus leaving them vulnerable to malicious or ineptly written PKGBUILDs. That is why AUR helpers are not officially supported on Arch (even though everyone uses them, of course). There are no AUR helpers in the official Arch repos, and for a good reason.
EndeavourOS made a decision to ship yay by default. I’m not sure if that’s a good decision or not, but in any case, you should heed the warnings and invest some time and effort into understanding not only the program yay but the whole process, before you willy-nilly install stuff from the AUR.
I just have to join in on this because i don’t necessarily understand why so many people have issues with yay. I know very little about package builds and yet i hardly ever have an issue with it. I don’t know what users are trying to do because it’s pretty simple. All the work is mostly done for you. If the package build is correct it will install.
That’s the ideal case… Last time I attempted to follow the arch wiki and install manually an AUR package it failed. I guess I need to spend more time on it, I just lost patience too quickly.
