Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#29112 - [pacman] The "--needed" flag attempts to pull packages that are not "needed"
Attached to Project:
Pacman
Opened by Hugo Osvaldo Barrera (hobarrera) - Sunday, 25 March 2012, 15:00 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 03:39 GMT
Opened by Hugo Osvaldo Barrera (hobarrera) - Sunday, 25 March 2012, 15:00 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 03:39 GMT
|
DetailsDescription:
When attempting to sync a package, and it is being "provided" by another currrently installed package, pacman prompts to replace the installed one with the other one. This also happens when the "--needed" flag is used; the usage of this flag should force this package to be skipped, just as if it were installed. Additional info: Never happens on a clean install, though especially common when using multilib. Steps to reproduce: # pacman -S --asdeps --needed binutils resolving dependencies... looking for inter-conflicts... :: binutils and binutils-multilib are in conflict. Remove binutils-multilib? [y/N] Expected output: # pacman -S --asdeps --needed binutils resolving dependencies... looking for inter-conflicts... warning: binutils is up to date -- skipping there is nothing to do |
This task depends upon
Comment by Dave Reisner (falconindy) -
Sunday, 25 March 2012, 20:03 GMT
Expected behavior. If testing and multilib-testing are out of sync (i.e. the toolchain rebuild hasn't hit multilib-testing yet), binutils exists as a valid upgrade path to binutils-multilib because of the provide on the latter. Therefore, --needed has no effect because an upgrade exists. The only "bug" here is that the toolchain isn't yet in multilib-testing.
Comment by Hugo Osvaldo Barrera (hobarrera) -
Sunday, 25 March 2012, 21:54 GMT
But this also ocurrs if both packages are at the same version. Shouldn't there be a simple way around this?
Comment by Dave Reisner (falconindy) -
Sunday, 25 March 2012, 21:59 GMT
Don't try to install packages that aren't installed and expect them not to be? I still think the behavior is correct here. We always favor an exact package name match before falling back on a provider.
Comment by Hugo Osvaldo Barrera (hobarrera) -
Monday, 26 March 2012, 07:33 GMT
I understand that this is fine by default, but I belive the "--needed" flag should change this: I don't *need" packageX, if packageY already provides it.
Comment by Allan McRae (Allan) -
Saturday, 09 February 2013, 03:39 GMT
Needed means "needed to complete the requested transaction". If "pacman -S binutils" needs to install binutils, then "pacman -S binutils --needed" will still install it.