At least with VLC, there are plugins that are used by the entire system. LibreOffice shouldn’t be a major issue, but other users here can likely give you better answers regarding that.
But for packages like LibreOffice or VLC, it should be okay to add them to the blacklist, right?
Why not just uninstall them when you don’t need them? I did so with the vlc plugins, no problem so far.
As @Dagrod correctly pointed out: you should not blindly add packages to the IgnorePkg list, this should be a last resort and a temporary workaround only, not the solution to anything.
Although, come to think of it, I heard someone say that they add the kernels and mkinitcpio to IgnorePkg to pin them to a certain version…
It’s not that I don’t need them. Sometimes I just like a particular version of an app, so I want to keep using that one.
Sorry, but that’s nonsense. Software versions aren’t cars or women …
“Sorry, but that’s nonsense. Software versions aren’t cars or women…”
Dagrod, I don’t know why you’re judging me just because I like a particular version of an app. Has it ever occurred to you that maybe the devs made changes to an app that I didn’t like and I would prefer the previous iteration?
I’m not judging you, but sticking indefinitely with a version of a specific piece of software that will soon be outdated—just because you “like it better”—is really stupid, sorry.
I do understand this sentiment. Back when I hated myself and still used Windows, I stayed on GIMP 2.6 for years because after that point they dropped Lanczos interpolation from their image resizing tool. That’s all it took.
However, using IgnorePkg would absolutely be the last resort I would go to on an Arch based system in order to maintain a package’s version. Just because the package is an application doesn’t mean it’s not going to affect the rest of the system as well, since you’re also holding its dependencies hostage as well, and theirs, and theirs.
pacman is a pretty delicate balancing act, and it works extremely well as long as you adhere to its rules. Mess around with it and you’re basically just asking for system instability. A lot of new users run into this issue through a variety of means. Like over reliance on the AUR in which packages not as strictly maintained can cause version desyncs.
One thing you could do is “disconnect” an application from pacman, like using its Flatpak, Snap, AppImage, build it yourself, etc. Which will allow you to administer it outside of the native ecosystem and keep your system files safe.
Barring that, I think I’d sooner suggest leaving Arch entirely than to try and manage your system in this way. IgnorePkg should be an emergency measure.
absolutely
You say you’re not judging but you clearly are. Anyway, you keep doing that.
OK, I’m out now …
Thanks for the explanation! I’ve been updating all of my packages on Cachy so far so this isn’t going to be a problem. Never had the need to not update a package on Linux so far, but yeah I know what you mean. I still have an old version of a video editing software that I brought over from Windows. I still use it because they removed an output format and replaced it with one that just didn’t look that great in my opinion.
Oh. Don’t worry. I’m not adding anything to IgnorePkg list. I don’t even have LibreOffice and my VLC is up-to-date. I was just merely using those as hypothetical examples.
I find this association-chain of “using a thing” → “cars” → “women” pretty questionable, to be honest 
You should almost never do this and only temporarily. If you want to stick with an outdated software you should instead install it not through pacman.
Wise words.
Hi, so I actually was able to figure this out in around a minute.
What’s happening here is that there’s double listings inside the CachyOS repos for certain packages. One of them has the wrong release number.
In my case it was this right here:
As you can see, the cachyos repo has a pacman-contrib package that has a different release number than the rest.
Shelly is picking this up and deciding it needs an update, because they share a name, although that’s not the repo the user has that package installed from.
So, it’s actually working as intended. It’s informing the user of an upgrade to an existing package from a different repo they have available. They should still communicate that it’s a repo change though, which is the actual issue here.
The idea is the same for Flatpaks, if you have multiple repos Shelly is going to say there’s a newer version somewhere, even if you don’t need it for your current setup.
Ditto to the AUR, which is why it will show that you have potential upgrades from there even if you don’t have those packages installed from the AUR.
This has already been gone over, and this is not working as intended. A lower ranked repository should not register even if it has a package with a newer version. That’s why sudo pacman -Syu does not report there being a package upgrade. And if pacman doesn’t, neither should any update tool available.
Well, that depends on the intention of the developer of the GUI. They may see it as pertinent information for the end user. I’m operating from the assumption they “want” people to know upgrades are available if they so choose to select them. It’s not just a Cachy tool, it’s a general Arch tool that is trying to pool all potential variables.
It still shouldn’t be used for updates in its current state, because it’s not ready, but I don’t find the idea of it notifying when there’s new packages upstream to really be a problem.