Protect certain packages until full system upgrade

Basically, what I’m looking for is the reverse of “IgnorePkg”: Some way to prevent certain packages from being upgraded except during “pacman -Syu”.

The reason for this is that I have managed to break something important several times merely by doing partial upgrades. I try to install some package, its dependencies include a newer version of a package I have installed, I upgrade that dependency, and on the next boot my display manager fails to start. Stuff like that. It’s annoying.

I can’t memorize every package required by every important OS package, and apparently pacman’s version checks are incomplete, so I see no other way to prevent this from happening than protecting all dependencies of certain packages (Xorg, display manager, gpu drivers etc.) from being individually upgraded under any circumstances. Pacman should throw an error if I try to do so outside of the context of a full system upgrade instead of letting me set myself up for booting issues. But how do I achieve this?

Partial upgrades simply aren’t supported on arch. I doubt there is such a thing.

I don’t want partial upgrades, I want something to prevent me from doing partial upgrades.

I’m not asking for a way to install packages without their dependencies. I want pacman to tell me that I can’t install a package if its dependencies require upgrading a package on which a high importance package like Xorg or sddm depends.

Dependencies such as libraries that are shared between the package I’m trying to install and sddm.

Which can break sddm even when pacman doesn’t detect a conflict.

Pacman should throw an error

sudo pacman -Syu

will prevent you from doing partial upgrade.

Never run sudo pacman -Sy without -u.
Never run sudo pacman -Sy X to install a package X.

Before installing any package X make sure your system is fully updated, always, that is:

sudo pacman -Syu X

1 Like


I don’t think pacman can do such thing. You, on the other hand, could create a script that checks the dependencies of a package and looks for packages that you don’t want to be updated. Then throw an error yourself.

That’s a decent idea, I probably would have done this already but I’m not really sure how to make a script intercept a pacman call/interact with it in the way described. I know how to run a script before or after installing a package, but not how to have pacman provide it with a list of packages and then wait for a response. Well I guess I could write a wrapper. Just need to remember to actually use it instead of pacman -S.

You could just create a wrapper script that takes in the arguments and invokes pacman from inside the script.

But before that maybe wait a bit. Maybe someone else has an idea.

1 Like

I’m reading a bit on alpm-hooks and wrote this:

Operation = Install
Operation = Upgrade
Type = Package
Target = *

Exec = /usr/bin/depencycheck
When = PreTransaction


echo $packageList

The script works as intended, but the hook fails with:

:: Running pre-transaction hooks...
(1/1) install.hook
call to execv failed (No such file or directory)
error: command failed to execute correctly
error: failed to commit transaction (failed to run transaction hooks)
Errors occurred, no packages were upgraded.

I don’t understand why.

Edit: Oh because of the typo, duh!

Okay, stdin works fine when running the script from the command line, but in the context of pacman -S it gives me

/usr/bin/dependencycheck: line 3: /dev/stdin: No such device or address

Even though “NeedsTargets” is supposed to provide stdin to the Exec command. Weird.

pacman can do more than such thing, if you follow Arch guidance.
If you do not follow Arch guidance, you convert your system to a non-Archlinux distribution.

If you do as suggested, you will not have the OT problem.

This is the rule:

When you try to install a new program/package, you use this:

pacman -S <package-name>

If there is error for package not found, then use this:

pacman -Syu <package-name>

It is as simple as that. Anything beyond the above needs experience.

I thought we already did that by using EndeavourOS…
At least that’s what Arch maintainers say.

EnOS is as close as possible to a pure Archlinux system.
For the topic in discussion, EnOS is exactly Archlinux.

Nvm I get what you mean now.

1 Like

Is there some way to prevent database refresh without system upgrade then?

I tried putting this in .bashrc, but somehow the result is that it no longer accepts my password:

function sudo () {
    if [[ "$@" == "pacman -Sy" ]] || [[ "$@" == 'pacman -Sy '* ]]; then
        echo "Please use -Syu"
        /usr/bin/sudo $@

Edit: Nah, it works after I opened a new shell session. Must’ve been something wrong with the previous one.

Really? So, you think this is a solution? :rofl: :rofl: :rofl: :rofl:

Try these commands then:

sudo pacman -S -y
sudo pacman --sync -y
sudo pacman -yS
sudo pacman -Sdy
sudo pacman -Syd
sudo yay -Sy

So you’re telling me a bunch of command patterns I never use aren’t covered by my solution? Shocking.
I did make one for yay tho.

If people want this solution to work for their own exotic use cases, they can write their own code.

For my own use cases, I decided this is enough:

#Blocks sudo pacman -Sy
function sudo () {
    if [[ "$@" == 'pacman '*'-Sy' ]] || [[ "$@" == 'pacman '*'-Sy '* ]]; then
        echo "Please use -Syu"
        /usr/bin/sudo $@

#Blocks yay -Sy
function yay () {
    if [[ "$@" == *'-Sy' ]] || [[ "$@" == *'-Sy '* ]]; then
        echo "Please use -Syu"
        /usr/bin/yay $@

Plus perhaps I wanted a way to circumvent it? Like maybe when I want to refresh now and upgrade later or something. I’m only interested in preempting my own thoughtless mistakes, not the thoughtful ones.

sudo yay

I don’t think so.

Your system so your rules. hope you enjoy your system ( for how ever long it last )