If you’ve spent any time on the Arch Wiki or community forums, you’ve probably come across this warning: Never run pacman -Sy package_name. Never run -Sy on its own and walk away. This is known as a partial upgrade. Some people follow this rule almost like a superstition. They avoid it because they’ve been told not to, not because they understand what’s happening underneath.

That’s the part worth fixing. The rule is easy to remember. Understanding the mechanism behind it is what makes it stick. Once you see it, you’ll understand exactly why pacman -Syu is the safe method to do your update.

Why Arch updates work differently

There are two main types of Linux distributions. They are point-release (or fixed-release) distributions and rolling-release distributions. Arch Linux follows the rolling-release model.

Now, let me show you the practical difference with an example.

Suppose I’m using Linux Mint or Debian and my web browser needs an urgent update. I can update the browser without upgrading every other package on my system. The rest of the system can remain at its current versions, and that’s a normal part of how a fixed-release distribution is maintained.

Now suppose the same thing happens on Arch Linux. I need the latest version of my browser, but I haven’t updated the rest of my system for a while. It might seem reasonable to upgrade only the browser and leave everything else alone.

Technically, I can try to do that. But on Arch, packages in the repositories are continuously moving forward together. The latest browser package may have been built against newer versions of libraries and other packages than the ones currently installed on my system.

If I refresh the package databases and install only the new browser, I mix packages from the current repository state with packages from an older system state. This is what Arch calls a partial upgrade, and partial upgrades are unsupported.

So on Arch, if I need to upgrade a package from the official repositories, the safe approach is to update the system as a whole rather than selectively upgrading only that package.

This difference is important because Arch’s repositories are constantly changing. Think of this as a remote package environment that is continuously moving forward.

pacman command you type on your computer, is a program installed in your computer. So how does pacman know which packages and which versions of those packages are currently available in the remote repositories?

How pacman knows what’s available

Pacman maintains two distinct types of package databases on your computer. Together, they allow pacman to know both what is installed on your system and what is available from the repositories.

1. The sync databases — “What is available?”

The sync databases contain information about packages available from the configured Arch repositories, such as core and extra.

They are stored under:

/var/lib/pacman/sync/

These are local copies of repository metadata. They contain information pacman needs about available packages, including their versions and dependencies.

When you run:

sudo pacman -Sy

pacman refreshes these local sync databases using the current repository databases from your configured mirrors.

An important point is that refreshing the sync databases does not upgrade any installed packages. Pacman now has current information about what is available remotely, while your installed system remains unchanged.

2. The local database — “What is installed?”

The local database records information about packages currently installed on your computer.

It is stored under:

/var/lib/pacman/local/

When pacman installs, upgrades, or removes a package, it updates this database accordingly. It records information such as the installed package version, dependencies, and the files belonging to that package.

Because this information is stored locally, pacman can answer questions about your installed packages without contacting the Arch repositories.

For example:

pacman -Q

can list your installed packages entirely from local information.

A simple way to remember the distinction is:

Sync databases  → What packages are available?
Local database  → What packages are installed?

Pacman uses these two views together when managing your system. Understanding the difference between them is the key to understanding what happens when you run pacman -Sy and why pacman -Syu behaves differently.

How a partial upgrade happens

Let’s see what happens when we run:

sudo pacman -Sy package_name

Step 1: Pacman refreshes the sync databases

The -y option refreshes the sync databases under:

/var/lib/pacman/sync/

Pacman now has current information about the packages available in the configured repositories.

But nothing installed on your system has been upgraded yet.

At this point, pacman’s view of the repositories is current, while your installed system may still contain package versions from the last time you performed a full system upgrade.

Step 2: Pacman looks up the requested package

Pacman uses the newly refreshed sync databases to find package_name and determine its dependencies.

The requested package therefore comes from the current repository state, not necessarily from the repository state that existed when you last upgraded your system.

Step 3: Pacman resolves the transaction

Pacman checks the requested package’s declared dependencies against the packages installed on your system and the packages currently available in the repositories.

If dependencies need to be installed or upgraded to satisfy the transaction, pacman can include them.

But this is the important part:

sudo pacman -Sy package_name

does not tell pacman to perform a full system upgrade.

Pacman resolves the transaction needed for the package you requested, but unrelated installed packages are not automatically brought forward simply because newer versions exist.

You can therefore end up mixing packages from the current repository state with packages from an older system state.

That is a partial upgrade.

Why this can cause problems

A useful mental model is to think of the Arch repositories as a package environment that is continuously moving forward.

Packages in that environment are not isolated. They may depend on other packages or be built against shared libraries that are also evolving.

Imagine your system was last fully upgraded some time ago:

Your installed system          Current Arch repositories

Application A   older         Application A   newer
Library X       older         Library X       newer
Library Y       older         Library Y       newer
Other packages  older         Other packages  newer

You then refresh the sync databases and install one package from the current repositories:

Your installed system

Application A   older
Library X       older
Library Y       older
New package     current   ← brought in from current repositories
Other packages  older

Software often relies on other packages and shared libraries in the same environment. If you update only part of the system, you can end up mixing newer packages with older ones that were not meant to work together.

This is how a partial upgrade can leave your system in an inconsistent state.

The correct Arch approach

Instead of refreshing the package databases and selectively installing a package: we can perform a full system upgrade while installing the package:

sudo pacman -Syu package_name

The u makes the crucial difference.

  • Pacman refreshes the sync databases
  • Upgrades installed packages for which newer versions are available
  • Resolves the requested package and its dependencies
  • and performs the transaction together.

Instead of pulling one piece from the current repository environment into an older system, you bring your installed system forward as a whole.

What about pacman -S package_name?

There is one more command worth understanding:

sudo pacman -S package_name

Unlike pacman -Syu package_name, this command does not refresh the sync databases. Pacman uses the repository information it already has locally to find and install the package.

This can be useful when installing several packages within a short period of time.

For example, suppose I have just performed a full system upgrade:

sudo pacman -Syu

Later that day, I decide to install another package:

sudo pacman -S package_name

There is no need to download the repository databases again just for that installation. Pacman can use the sync databases it already has.

But what if I haven’t refreshed those databases for two weeks?

In that case, pacman -S package_name still uses the old repository information stored on my computer. The package version recorded there may no longer be available on the current mirror, because Arch’s repositories have continued moving forward.

The installation may therefore fail when pacman tries to download a package version that has already been replaced.

So my rule is simple: if my sync databases are old, I don’t solve the problem by running:

sudo pacman -Sy package_name

Although this quickly refreshes my view of the repositories, it then selectively installs the requested package without upgrading the rest of the system. This can create that problematic partial upgrade.

Instead, I bring my system and sync databases forward together:

sudo pacman -Syu package_name

So pacman -S package_name is useful when I already have reasonably current sync databases and don’t need to refresh them again. If those databases have become old, I perform a full system upgrade rather than refreshing them only for a selective package installation.

Then why doesn’t Arch block pacman -Sy?

Okay, it’s clear pacman -Sy package_name can lead to a partial upgrade, then you might wonder, why doesn’t Arch simply prevent you from running it?

Because pacman -Sy itself is not an invalid operation. It refreshes the sync databases, and there are legitimate situations where an administrator may need to do that without immediately upgrading the system.

Arch generally gives you control over your system rather than trying to prevent every potentially unsafe operation. It assumes that you, as a system administrator, understand the consequences of the commands you run.

Pacman gives you the tools. It does not make every system management decision for you.

So, understand why pacman -Sy package_name is dangerous. Don’t memorize it as a command that you shouldn’t run.

Got questions, corrections, or suggestions?

Open an issue on GitHub or drop me an email.

dumidusw
Dumidu GitHub Profile • Email