FS#23424 - Do not report versions with -Rd

Attached to Project: Pacman
Opened by Allan McRae (Allan) - Friday, 25 March 2011, 04:41 GMT
Last edited by Dan McGee (toofishes) - Monday, 28 March 2011, 01:51 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Dan McGee (toofishes)
Architecture All
Severity Very Low
Priority Normal
Reported Version 3.5.1
Due in Version 3.5.2
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:
Currently both "pacman -R foo" and "pacman -Rd foo" show the version when outputting dependency issues.

e.g.
> pacman -Rd filesystem
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: dbus-core: requires filesystem
:: fakeroot: requires filesystem
:: hal: requires filesystem>=0.7.1-5
:: mkinitcpio: requires filesystem>=2009.01-2
:: util-linux: requires filesystem

With -Rd the version comparison (e.g. with hal and mkinitcpio above) should be omitted from the output.
This task depends upon

Closed by  Dan McGee (toofishes)
Monday, 28 March 2011, 01:51 GMT
Reason for closing:  Fixed
Additional comments about closing:  Commit 68701a98aff46821e7e
Comment by Dan McGee (toofishes) - Friday, 25 March 2011, 20:44 GMT
Patches for this on my maint branch:
http://code.toofishes.net/cgit/dan/pacman.git/log/?id=68701a98aff4
Comment by Xavier (shining) - Tuesday, 29 March 2011, 07:38 GMT
A question we had back then : do we want to strip version from local db too when doing -Sd ?
compute_dep_string is used by local_db_write.

Stripping all dep version information for new/upgraded packages sounds a bit weird.
That's why the compute_dep_string patch we had on the ML some times ago was either never applied, or reverted (don't remember exactly).

Second less important question : whats the impact of strict or tolerant depcmp in resolvedep ?
Comment by Dan McGee (toofishes) - Tuesday, 29 March 2011, 15:40 GMT
I'm not sure what you're saying on the first question. The only time we ignore dependency versions (or ignore them completely) here is during comparison, never during the actual load of the data or writeback of that package data to our local database. Your own tests did a good job of ensuring this- sync-nodepversion01.py for example checks the DEPENDS version in the local database after the operation. I would not have made these changes without significant test coverage backing me up.

Second question. strict/tolerant are no more, so let's call it filtered vs. unfiltered here. resolvedep() is called in two places:
* alpm_find_dbs_satisfier(): we have zero guarantee of being in a transaction here, so we can't use tolerant/filtered behavior in any sort of consistent fashion unless this is a flag on the handle or the call to this function.
* _alpm_resolvedeps(): Called as a very early step in sync_prepare, we still want to pull as many matching dependencies as possible, unless I'm thinking wrong. Even if we do these with versions attached, you still have the opportunity later to actually check the list without versions when checkdeps as called. There was no test case to bust this solution, so until one is provided I don't believe I caused any regressions.
Comment by Xavier (shining) - Tuesday, 29 March 2011, 16:50 GMT
Oh sorry for the noise, I totally misread the compute_dep_string patch :) It's indeed perfectly fine.

About resolvedep, I agree that it does not matter until we find a test case.

Loading...