[SOLVED]Yay packages to exclude


I have a google-chrome update from the AUR and when I run yay -Syu --aur it asks Packages to exclude: (eg: "1 2 3", "1-3", "^4" or repo name) I’ve searched the man, google and this forums old posts but I can’t find an explanation about this.

I’m not sure why I would want to exclude any packages, they are updates and I thought partial updates could break the system. There doesn’t seem to be a way to exclude 0 packages.

I’m sure this is a very basic issue, but I don’t get it and couldn’t find anywhere that explains it.

Thanks in advance,


1 Like

there is no issue and you do not need to exclude packages to proceed, it gives this only as an option, could be you have an UAR build that would need hours to build, and you do not want to do this currently or similar…

1 Like

Thanks for your reply @joekamprad.

So how do I not exclude any packages?

press enter
without any input givin to yay

1 Like

lol :smile: That easy.

Amazing how the smallest issue is a mountain until you know how then its a hole in the street.

Thank you @joekamprad.

It’s a shame I can’t find any guide explaining these options.

Still when it says packages to exclude I don’t get it. I only have one update google-chrome so why the numbers? Also what is packages to cleanbuild about?

Its called example 1,2,3 not actual , Clean build is again what it says if you choose clean build it removes all traces of the package and rebuilds from scratch.


Thank you @mandog, I still don’t get it though.

If anyone knows of a guide or link to a post/article that explains in depth about these options I would really appreciate it.

Maybe most people find these options self explanatory, sadly I’m not one of them.

Well - the first thing to check is the man pages, I guess:

man yay

which gives you ALL the options, with a short explanation. Pretty dense information, though!

When used for the AUR, yay (or any other AUR helper) has several tasks to do. When updating:

  1. Check to see if any new versions/updates are available
  2. Determine which ones you wish to update. There can be several reasons for NOT doing an AUR-based update. It might take longer than you have right now. It might be you’ve heard not to do it (yet) on one particular package. It might be you want only one of them done now - so you can use it right away. So - the pkgs to exclude prompt. This works the same way as the choice list of packages to install when doing that…
  3. Check if you want a Clean build. If you had a problem with updating before (the build stopped part way through), this allows you to redo the whole thing. Sometimes ‘support’ packages have been updated in the meantime, for instance, which you need to incorporate into the new build (even though usually automatically).
  4. See if you want diffs shown. This will display the differences between the build instructions from last time, and how they are now. Most often this is just a line stating the version change, and mostly ignored.
  5. Actually follow the instructions in the PKGBUILD to create an install capable package - the same you would if you were building it yourself
  6. Calls pacman (with -U) to install the resulting package - getting the sudo password if necessary.

I hate to say it - but the Arch wiki has the most information on how a package is built, and how pacman works. Google-fu can find other explanations, of course, and some of them might be useful!

Enjoy… :grin:


“Hello, I’m YAY, your AUR helper.
Would you like to update all packages or skip a few and update them later?”

This is what yay asks you.

2 Packages to upgrade.
2  aur/wps-office ->
1  aur/wps-office-mime ->
==> Packages to exclude: (eg: "1 2 3", "1-3", "^4" or repo name)

See the numbers on the left 1, 2, its asking you if you want to exclude one both or none.

1 Like

Thank you @freebird54. That explanation helped a lot giving me the larger picture.

I have read (as thoroughly as I could the Arch wiki page regarding building packages and have built and packages checking the package build file, mainly checking the source. I just haven’t been able to find anything on the wiki or google about yay’s options.

A while back when I was using Arch I actually found an old post on this forum explaining about diffs to show which helped me first installing with yay.

Any way thank you for your explanation it did help clearing the fog. :smile:

Thank you @mandog, this did help. I think I just needed to know a bit more about scenarios when the options would be applicable and how/why to use them.

many thanks

@Lemon :grinning: :ok_hand:

Thank you All.

I’ve found the man pages almost as difficult to attain information from as the Arch wiki. For example I must have read it somewhere (can’t remember where) so whenever I edited .bashrc I would run source .bashrc. I tried doing it on .vimrc and got lots of errors. I couldn’t find anywhere that explained when or what files should be sourced. I checked man source lol and couldn’t understand a thing.

I’ve had very little education other than what I’ve taught myself, left school before g.c.s.e’s due to tragedy in my family. But I don’t define intelligence according to what you’ve been able to learn and what you know. It’s just a shame on the issue of learning Linux all the manuals are explained in a difficult to understand type of way. The best explanations I’ve had are from people like yourself who are trying to actually explain the topic or how to guides on google.

Anyways, hopefully in time I’ll start to pick up more from the manuals. I do think I am understanding a bit more than I was before and that is progress.

1 Like

I have found that the man pages are worth a look - if not necessarily the way you expect them to be! Here’s a take on the ‘process’ involved in my case over the years…

  1. You already know that X should do what you want - and just want the exact options you need to make it happen.
  2. You know a bit about X, and wish it did things a little differently… maybe it does, and you can see this
  3. You don’t know the command at all, but a quick skim can give you an approximation of what it can do.
  4. You saw a mention of this command, and just want to see how it works. Perhaps it was in a how-to you saw online, and you didn’t see how it fit in. Enlightenment awaits!
  5. You’ve seen a ‘list of stuff you should know’ - and this is one the things you don’t. Often the first time through a man page, you only pick up one or two of the things it can do - or maybe only an impression. When you look again later, more of it will ‘hang together’ than the first time through. Maybe the third time will be the charm…
  6. You saw something in a previous man page (a ‘See also’ mention, perhaps) - and this may suddenly make the whole purpose clearer!

All in all - don’t expect the man page to be a tutorial, and get what you can each time through one of them. Perhaps it will prompt you to find a tutorial, or walk-through, or a better explanation online. Even after that, a quick look at the man page will still be useful, to make sure it was what you thought it was!

Another way ‘in’ can be to see what is getting updated - and see if it has a man page. All those mysterious names… but they can become more familiar over time if you can ‘slot’ them into an overall picture of what’s happening under there…

BTW - the source command means to read and execute the bash commands included within it - basically run that script. In the case of .bashrc, these are the commands that set up your session. If you make changes, they will only be in effect AFTER the script has been run - so you can logout and back in, or sit through a reboot - or just make sure you ‘source’ the changed file to avoid going through all that :grin:

The most important thing is not to expect to pick it all up at once - or in any particular order. Man pages are just a quick reference - and ONE of the ways to learn stuff. After trying a few of the methods mentioned here, you can always ask someone here. A first impression might be that everyone knows everything - but that isn’t so - it is just that person answering has perhaps done that particular thing before, or has that same hardware, or helped on that before - or just has more practice finding things out! Before you know it, you may be helping someone else on something you ‘fixed’ yourself previously…


@freebird54 wonderful advice which I will take on board. Quite often I have to sit back and take a deep breath because it does all get a bit overwhelming. Definitely I need to not rush or want to get it all resolved at one time, so I can take my time reading relevant pages and then re reading them again. Sometimes that is harder to do than other times, for example if my Wifi just stopped working.

It’s also a lack of confidence that I need to contend with, which is a result of not having enough practice, experience and knowledge. Patience and consistent hard work is the key I think.

Again thank you for your advice, and also for spotting and answering the side point about sourcing .bashrc.