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
Task Type Bug Report
Category General
Status Assigned
Assigned To Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version 1.6.0
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

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
   pacmanqdt (1.7 KiB)
   packs (162.2 KiB)
This task depends upon

Comment by Allan McRae (Allan) - Saturday, 06 February 2010, 12:31 GMT
A lot of those look like they would have been installed as makedepends. e.g. git for gtkpod-git...
Comment by Nagy Gabor (combo) - Thursday, 11 February 2010, 19:54 GMT
Which packages of -Qdt are considered as false positive?

@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.
Comment by Allan McRae (Allan) - Thursday, 11 February 2010, 22:25 GMT
Hmmm... when did we add that to pacman? I thought reinstalling a package did not change its install reason.
Comment by Nagy Gabor (combo) - Thursday, 11 February 2010, 23:59 GMT Comment by Xavier (shining) - Friday, 12 February 2010, 01:27 GMT
Reinstalling a package does not change its install reason.
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...
Comment by Allan McRae (Allan) - Friday, 12 February 2010, 01:37 GMT
Oh, I thought removing the package and installing it was the way to change install reason and that was the reason for the -D stuff that was proposed. Seems I was wrong!

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...
Comment by Xavier (shining) - Friday, 12 February 2010, 01:50 GMT
Actually -S does remove/install internally so that's the first reason why -D is interesting (just need to edit one file, instead of removing all package files and extracting them again.) Second reason is that this requires the pkg.tar.gz , so it even has to redownload it if not available, all this to change one field in the database.

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 :)
Comment by Allan McRae (Allan) - Friday, 12 February 2010, 02:00 GMT
> If first test failed, try again with no version ?

That is what I thought. If "pacman -T dep" fails, try again after stripping any versioning. If that succeeds, do <something>...
Comment by Rémy Oudompheng (remyoudompheng) - Tuesday, 24 May 2011, 06:24 GMT
Is this bug still valid?
Comment by Allan McRae (Allan) - Tuesday, 24 May 2011, 06:40 GMT
Yes. Some parts are fixed, others are not.
Comment by Dan McGee (toofishes) - Wednesday, 01 June 2011, 21:38 GMT
We almost need an in-between the default "--asexplicit" and "--asdeps" here; something like "--asdepsifinstallingbutnotupgrading" which is obviously a horrible name but sums up the issue at hand.
Comment by Rémy Oudompheng (remyoudompheng) - Thursday, 02 June 2011, 06:45 GMT
What about --missing-asdeps or --new-asdeps? What is your opinion about the following scheme:
- 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.
Comment by Allan McRae (Allan) - Thursday, 02 June 2011, 06:57 GMT
None of that is needed... What we need to do is fix makepkg. Here is the bug:

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.
Comment by Dan McGee (toofishes) - Thursday, 02 June 2011, 12:57 GMT
I should have mentioned more in my comment- I definitely realized this was the "update the system" case, but outside of a rolling-release distro it might make more sense to allow such stupidity. I'm really up for either solution as long as someone else does it; Allan's suggestion is likely easier and would at least prevent people from shooting themselves in the foot.

Maybe -T can return one code for any missing deps, and a different one for right deps, wrong versions?
Comment by Allan McRae (Allan) - Thursday, 02 June 2011, 13:00 GMT
I thought of having makepkg do "pacman -T foo>=2" and if that failed try "pacman -T foo". If both failed, continue as normal. If only the first failed, print an error that the required version is not installed and abort with a message suggesting that a system update might fix it.
Comment by Nagy Gabor (combo) - Thursday, 02 June 2011, 18:03 GMT
Well, I would prefer something like this, when checking foo>=2.0:

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.
Comment by Nagy Gabor (combo) - Thursday, 02 June 2011, 18:08 GMT
One more problem is that the above method may need two "pacman -S" commands, which is uglier than the current one "pacman -S --asdeps" command.
Comment by Pablo Lezaeta (Jristz) - Thursday, 31 October 2013, 11:38 GMT
I recheck this and the ouput remain as:
pacman -Qdt for makedeps no more needs
pacman -Qm for foreign packages
Then this isnot complettly fixed, but almos the result remain the same

Loading...