> This is especially useful for cases where the user is selectively upgrading packages, but a package breaks due to a rebuild or similar.
Partial upgrades aren't supported.

This option used to exist but it was removed along with SyncFirst because of the problems it causes. You'd need a more compelling (supported) case for this to be considered for reintroduction.

What sort of issues did it cause?

I get that partial upgrades aren't supported, but they are sometimes necessary; eg in the case where an update is known to break a system but the culprit itself isn't known.
To be clear, this would be an *opt-in* flag, not default behaviour. If the issues are minor and infrequent, the flag itself may be documented as recommended against (Much like --force and plenty of others).
The current alternatives are pretty silly... one from IRC (though could be improved a lot): <Ogion> jleclanche: ruby -e 'print("echo pacman -S ", ARGV[0], `LC_ALL=C pacman -Si #{ARGV[0]} | egrep "^Depends On"`.split.drop(3).join(" "))' arandr

The other argument I could give you is when a package is broken but the breakage may be caused by any of its libs. A pacman -S --deps --cascade (or whatever) could be a better alternative to pacman -S.

pacman -S $(pactree -u <package>)

Yeah, that is pretty silly. Here's a far better alternative:

pactree -d1 -u $package | pacman -S $package -

The historical background on why not to do this is on the bug tracker. SyncFirst provided the behavior of what my shell pipeline does, and it was insufficient because it lead to broken dependencies elsewhere during the transaction. So, we applied recursion (essentially calling pactree -u $package | pacman -S $package -). Now you break uninvolved programs because you updated a reverse dependency they can't load/interface with.

I see.

Well, ultimately adding this option (back) is up to you. I think theres a case for it (namely, even if the partial upgrade argument is not accepted, the broken packages one is valid). I don't think anything involving pactree is an acceptable alternative; it's not a package installed by default and people can't find out about it by just reading pacman --help, which is where they're most likely to look when doing this operation.

2c

> I don't think anything involving pactree is an acceptable alternative; it's not a package installed by default
Uh, really? pactree is part of pacman proper.

Disregard that comment, I was thinking of pkgfile.

I'll note that partial upgrades not being supported is an Arch issue and not a pacman one...

Closing as won't implement given we provide all needed tools to do this.