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#15500 - repo priority for provisions

Attached to Project: Pacman
Opened by Pierre Schmitz (Pierre) - Monday, 13 July 2009, 17:30 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 05:11 GMT
Task Type Bug Report
Category General
Status Assigned
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version git
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

What we have:
* kde-unstable repo on top of all others in pacman.conf
* digikam in extra which depends on kdegraphics which is in extra, too
* The kde-meta-kdegraphics package in kde-unstable replaces, conflicts and provides kdegraphics

If we don't have digikam installed before pacman wants to pull in kdegraphics from extra as dep and ignores the package in kde-unstable.

It looks like pacman does not honor the replaces entry during dependency resolution.
This task depends upon

Comment by Nagy Gabor (combo) - Tuesday, 14 July 2009, 15:51 GMT
"It looks like pacman does not honor the replaces entry during dependency resolution."
Pacman ignores replaces field during dependency resolution, it is considered with -Su only.

Provisions are honored, but resolvedeps searches for literal first.

It makes sense to change this behavior to the following (if found, stop):
For each repo in syncdbs{
1. find literal
2. find provider}

This is similar to the new replaces behavior (see commit 882bff36).
Opinions? I am a bit unsure and this is a minor "issue".
Comment by Nagy Gabor (combo) - Tuesday, 14 July 2009, 15:55 GMT
I meant "search for" in the pseudo-code, of course.
Comment by Xavier (shining) - Wednesday, 15 July 2009, 09:11 GMT
Why not, I am not against this change, it is a special case anyway so should not be a big deal.
Comment by Xavier (shining) - Saturday, 12 September 2009, 11:01 GMT
last comment from nagy :
"we have a show-stopper(?) here, again: speed
literals are found quickly, whilst checking provisions is slow...
(with cold cache)"

so won't implement ?
Comment by Nagy Gabor (combo) - Saturday, 12 September 2009, 13:11 GMT
I think we should mark this FR as pending. When in the late future we will have fast db back-end, we can implement this. ;-)

Personally I like this idea, but atm this would cause notable slow-down. (Even with -Su, because %FORCE% and %REPLACES% are in desc, but %PROVIDES% is in depends. Great...)

Loading...