FS#18193 - Pacman failed to find unused dependencies
Attached to Project:
Pacman
Opened by Mete Çetin (metecetin) - Saturday, 06 February 2010, 12:06 GMT
Last edited by Allan McRae (Allan) - Tuesday, 29 December 2020, 13:29 GMT
Opened by Mete Çetin (metecetin) - Saturday, 06 February 2010, 12:06 GMT
Last edited by Allan McRae (Allan) - Tuesday, 29 December 2020, 13:29 GMT
|
Details
Linux linux 2.6.32-ice #1 SMP PREEMPT Mon Jan 11 04:50:15
CET 2010 i686 Intel(R) Pentium(R) M processor 1.73GHz
GenuineIntel GNU/Linux
Pacman v3.3.3 - libalpm v4.0.3 pacman -Qdt returns too many false positives. (please look at attachment) [mete@linux ~]$ pacman -Qm gtkpod-git 20100119-1 ifuse 0.9.5-1 kotaci 0.6-1 libflashsupport-pulse 0-3 libgpod-kmaglione-git 20100119-1 libiphone 0.9.5-1 libplist 0.16-1 limewire 5.4.6-1 mplayer-svn 30226-1 shorewall 4.4.5-1 subtitlecomposer 0.5.3-2 usbmuxd 1.0.0-2 xine-lib-pulse 1.1.17-1 |
This task depends upon
@Allan: I can see a little problem in makepkg: As I see, if a _versioned_ dependency is not satisfied, pacman -S --asdeps is called. However, it can happen that pacman just _upgrades_ an old version of the package, and changes the install reason to dependency.
But reinstalling with --asdeps changes it. Otherwise we would have no way to change reason of an existing package (well, removing it and re-install it, but that would be weird).
For what makepkg needs, this behavior sucks though...
How would be best to handle this in makepkg? We could be more clever and test whether the reason a dep is not satisfied is due to versioning, but what to do if that is the case? Upgrade it or abort with an error saying to update the packages/system? The second is actually a lot safer...
Otherwise, it does not sound too practical to detect this in makepkg. How would we do ? If first test failed, try again with no version ?
And yes, it's funny to see that makepkg itself could cause partial upgrades, that we all advise against :)
That is what I thought. If "pacman -T dep" fails, try again after stripping any versioning. If that succeeds, do <something>...
- when initializing a transaction, libalpm receives pmpkg_t structures where the package reason is already set by the frontend, to either EXPLICIT, DEPEND or DEFAULT
- libalpm declares these transaction flags: ASDEPS, ASEXPLICIT
- when preparing the transaction:
* implicit dependencies get reason DEPEND,
* upgraded packages with reason DEFAULT get the reason of the already installed package (unless FORCEREASON is set)
* new packages with reason DEFAULT get the reason DEPS/EXPLICIT depending on the transaction flags
the current behaviour of pacman --asdeps would set all reasons to DEPEND, pacman --asexplicit set all to EXPLICIT, and pacman --asdeps-but-not-for-explicit-being-upgraded would set reasons to DEFAULT but the transaction flag to ASDEPS.
makepkg sees a "foo>=2" makedepend so runs "pacman -T foo>=2" but the system has foo=1 installed so that returns a fail. Now pacman does a "pacman -S --asdep foo>=2" and installs "foo=2" to satisfy this. Note that foo is now installed as a dependency even if it was not originally. So now a "pacman -Qqtd" returns "foo" when it possibly should not.
Note... partial upgrade alert! So this only occurs when people do "pacman -Sy" at some stage on a rolling release system. To stop this occurring, makepkg needs to distinguish between failures to satisfy dependencies that are not installed and those that have incorrect versions. If it is a version failure, makepkg needs to abort and tell the user to update their system rather than updating the package itself.
Maybe -T can return one code for any missing deps, and a different one for right deps, wrong versions?
0. Forget about the -Sy issue.
1. If foo is not satisfied, do "pacman -S --asdeps foo"
2. If foo is satisfied, but foo>=2.0 isn't, do "pacman -S foo"
If we were too strict due to the -Sy issue, makepkg would be really annoying imho.
Unfortunately the above method is not perfect neither, because of providers... So in some _really_ edge cases, unwanted "explicitly installed" packages can appear (foo is satisfied by foo, foo>=2.0 is satisfied by not installed foo-ng, plus foo-ng and foo are not in confict).
So the most precise (and ugly :) solution would be Dan's --asdeps-but-not-for-explicit-being-upgraded (hidden?) pacman switch.
pacman -Qdt for makedeps no more needs
pacman -Qm for foreign packages
Then this isnot complettly fixed, but almos the result remain the same