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#22660 - pacman -S and -U with duplicated targets
Attached to Project:
Pacman
Opened by Xavier (shining) - Saturday, 29 January 2011, 21:10 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 05:12 GMT
Opened by Xavier (shining) - Saturday, 29 January 2011, 21:10 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 05:12 GMT
|
Detailscommit 4a72c0964abc4b4836c2aafb9c59716299215802
Author: Xavier Chantry <chantry.xavier@gmail.com> Date: Sun Oct 17 11:16:27 2010 +0200 pacman/upgrade: switch to new interface Note that there is a behavior change here : if the same package name appeared several times in the target list, the alpm_add_target interface chooses the new package, while alpm_add_pkg returns PKG_DUP. I don't see why we cannot unify the behavior of -S and -U, and just choose one behavior that applies to both. Otherwise, it's always possible to handle these different behaviors in the frontend, it just requires more work. 19:59 toofishes >> the backend should allow for flexible behavior 19:59 shining^ >> so a flag or two add_pkg functions ? 19:59 toofishes >> if we want to be smart, we should do that frontend- stinks becaue ew have to look at hte current target list every time and be smart 19:59 toofishes >> and remove then add 19:59 toofishes >> you don't even need flags or options, just do it the old fashioned way i would think 19:59 toofishes >> keep the operations simple 20:01 shining^ >> so allow the feature to be implemented in the frontend ? 20:03 toofishes >> oh damn 20:03 toofishes >> there is no way to remove a package from the *add* list once you put it there? 20:03 toofishes >> i was thinking add and remove operated ont he same list, silly me 20:04 shining^ >> yeah we cant 20:04 toofishes >> maybe one more function- alpm_replace_pkg(pmpkg_t *pkg) ? 20:05 toofishes >> so we would call alpm_pkg_add, get DUP back, and then do a vercmp to see if we should call replace? 20:05 toofishes >> replace should probably add too if not found, rather than error 20:05 shining^ >> vercmp with what ? :p 20:07 toofishes >> what do you mean? 20:07 toofishes >> we have two package objects at that point (if you find the one from the current target list) 20:08 shining^ >> yeah but .. looks weird to search target for dup in pkg_add , and then do it again in frontend when it returns PKG_DUP 20:09 toofishes >> then do the search first, i don't care :) 20:09 toofishes >> i figure 95% of the time you wno't have dups so who cares 20:09 toofishes >> what happens in the backend stays in the backend 20:09 toofishes >> and we're going to make pkg_find fast anyway with allan and i's hash changes 20:10 shining^ >> I wonder if the frontend can even use that 20:11 toofishes >> of course it can, it does 20:11 toofishes >> that would be stupid if it couldn't 20:13 shining^ >> where ? 20:18 toofishes >> well i suppose we need to expose a find_pkg method, but it should be there :) 20:20 toofishes >> apparantly we did not |
This task depends upon