what's the problem

pkg i PACKAGE, in a pacman install, calls pacman -Sy PACKAGE. It is a basic gotcha of Arch that you should never call pacman this way - they call this a "partial system upgrade" and the relevant Arch wiki page urges you to never do this, with big bold text and everything. I think the reasons we have pkg include saving keystrokes and providing a lower friction interface to package management for particularly new-to-linux users, both of which also point strongly away from unsafe defaults.

why's it a problem

IIUC, the reason Arch unambiguously says not to do this is that pacman simply does not check reverse dependencies when installing individual packages. Example:

• you have installed package browser version 0, which depends on libtls version 0, providing libtls.so.0
• after your last full upgrade with -Syu, repos pick up libtls version 1, a breaking change that only provides libtls.so.1
• you, against advice, pacman -Sy libtls
  • pacman will update the repo (-y), see the upgrade for libtls, depsolve its forward dependencies (maybe it needs an update to libcoolneoninstructions)
  • pacman will not consider whether your current installation of browser version 0 will still have its dependencies met after installing libtls version 1, and will happily do the upgrade and leave browser broken
• (example is a lib, but this is even more insidious and even more likely to bite someone with a package that provides binaries people will run explicitly but also files for other packages. imagemagick comes to mind.)

I think the idea here is that the consistency enforcement is in the repo metadata. pacman repos are supposed to always provide a set of packages whose dependencies are satisfiable within that set. -S libtls would have been safe, because all packages from the same sync are consistent; -Syu is always safe, because that actually considers every package and the repo-level consistency guarantees a single install "transaction"[0] where all dependencies are satisfied before and after it happens.

I am fairly certain that the apt stack does do reverse depsolving on every action and that no comparable problem exists - absent a bug or unrecovered interrupt, apt update && apt install PACKAGE always leaves a consistent system[1]. The operation of "update metadata and install one package" is safely expressible in apt and simply isn't in pacman, by design. I might be wrong there - if so, we should change both.

edit: Talked offline - apt has disappointed me here. termux/termux-app#4179 is this, for the apt stack.

[0] pacman upgrades don't appear to try for ACID. Maybe CID.
[1] Tiny soapbox: I suspect the absence of safety checks here is the dominant reason for pacman's famous speed. I guess it's just better

okay what do we do?

I see four credible options:

1. Nothing. Despite the unconditional urging against this from pacman's authors, triggering this problem requires a combination of a specific flavor of upgraded package and a specific flavor of user install op, without doing a system upgrade in the middle. It's also potentially recoverable with a system upgrade.

2. Change pkg i to use pacman -S. This preserves intent, but the version this selects may no longer be in the repos, and it produces a painful split from a support perspective: if you tell someone to pkg i something today and they report success, you can safely assume it's pretty recent. You'd need to ask if they're on apt or pacman to be able to do that, or you'd need to skip it and only tell people to pacman -Syu THINGISAIDTOINSTALL instead of using pkg at all, which undermines the value of pkg.

3. Change pkg i to use pacman -Syu. This potentially adds a lot of additional work to what would otherwise be a small download and install, which may surprise some users and be an actual problem for others, but gets full marks for doing what the user asked and for doing it safely.

4. Do both, with a safe default, a noisy preservation of the unsafe behavior for existing installs, and an opt-out:

• choose some envvar like TERMUX_PKG_PACMAN_UNSAFE
• if unset, print a warning with instructions, then -Sy
• if set to a falsy value, -Syu
• if set to a truthy value, -Sy with no warning
• change pacman setup scripts/instructions to set TERMUX_PKG_PACMAN_UNSAFE=false in profile.d or something, and maybe explain that this choice was made and how to reverse it

Opening this issue for opinions. If we decide to take anything like one of those options, I'll send the PR. My vote is for option 4.