Pacman

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.
Tasklist

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
Task Type Bug Report
Category General
Status Assigned
Assigned To Andrew Gregory (andrewgregory)
Architecture All
Severity Low
Priority Normal
Reported Version git
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

commit 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

Loading...