FS#11737 - replacing doesn't respect precedence.

Attached to Project: Pacman
Opened by Paolo (peoro) - Tuesday, 14 October 2008, 12:31 GMT
Last edited by Xavier (shining) - Monday, 27 July 2009, 14:06 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Xavier (shining)
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.1
Due in Version 3.3.0
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Pacman shouldn't (ask to) replace a package in a repository with a package in a "lower" repo.


I'm using the following repos (in this order): "core", "extra", "community" and "testing". The order is important because I want that packages from extra have precedence on packages from testing: that's it, I don't want to automagically replace xorg-server 1.4.2 (from extra) with the newer xorg-server 1.5.2 (from testing), and that's exactly how pacman works. Great!

The problem is with packages that replace others: if there's a package from testing which would replace a package from extra, pacman asks you what to do (and by default it would replace).
I think it's a buggy behaviour: in my opinion pacman should only (ask you whether to) replace packages that have at least the same "precedence" as the packages it's going to replace:
Replace X (which is not in a repository) with whatever/Y? -> OK
Replace X (from extra) with extra/Y? -> OK
Replace X (from extra) with core/Y? -> OK
Replace X (from extra) with testing/Y? -> NO! Pacman shouldn't ask me. I don't want to replace ("replace" in this case is a synonym of "upgrade") a package from extra with one from testing!
This task depends upon

Closed by  Xavier (shining)
Monday, 27 July 2009, 14:06 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed by commit 882bff36acad5
Comment by Xavier (shining) - Tuesday, 14 October 2008, 12:42 GMT
Pacman doesn't keep track of the repos from which packages are installed, so this is currently impossible to implement (even if you started to keep track of it, all previously installed packages still would not have this information).
Besides, pacman does ask the question, so you can refuse the replacement and get what you want.

The fact that pacman shouldn't ask you (even if we agreed on this) is a very minor detail, and difficult to implement.
Comment by Nagy Gabor (combo) - Friday, 17 October 2008, 10:51 GMT
First of all, I think that this is a minor issue: you can answer no ;-)

I agree, that the following behavior would be better:
For each local package 'pkg' do the following:
For each repos (priority kept in mind) check:
1. We have pkg in repo? If yes, stop, if it is an upgrade, select it.
2. We have a replacer in repo? If yes, stop and ask user.

So step 1-2 is analogous to "get pkg from syncrepo" (considering the replacements, too).
Comment by Nagy Gabor (combo) - Friday, 31 October 2008, 15:25 GMT
I started to like the idea of my previous comment. Although this is a very minor issue, interpret "foo replaces bar" as "foo is a new version of bar" could make our code cleaner. Imho sync.c/find_replacements is quite complicated atm.

We could easily integrate replacement check to sync_newversion. (In this case, foo can be a new version of bar, this seems rational.) For each repo first search for literal then search for replacer.

There is a little problem with this: pacman new version check. Atm this is done with the help of sync_newversion. In this case, search for replacer is needless. (Probably we won't rename pacman etc.) Literal would have priority over replacer, but now we want to this task per repo. In most cases the user's first repo is core, so pacman will find the package pacman, no other search is needed, OK. However, if his first repo is testing, the new method will search for replacer in testing, and "search for replacer" is a _slow_ task (with empty cache), because pacman must read many desc files. This can be a real issue in "pacman -S somepackage" task.
So we may give a new boolean replacements param to sync_newversion, I dunno.

Note, that the reworked -Qu would profit from the new sync_newversion, because atm %REPLACES% fields are ignored by the reworked -Qu.
Comment by Dan McGee (toofishes) - Saturday, 01 November 2008, 00:52 GMT
Performance things aside, any code simplification would be ideal. When/if I get around to implementing a tar-based DB reader, those concerns should no longer be relevant.
Comment by Nagy Gabor (combo) - Tuesday, 19 May 2009, 12:30 GMT
I think I misinterpreted your request a bit, but I think commit 882bff36acad5c47df5b35fd3afb411dc4f092b0 fixes your issue. From now on, pacman will ask you about the first repo, where replacers can be found. We cannot do more, because "pacman doesn't keep track of the repos from which packages are installed" (see Xav's comment).

So I think we can close this bug as "implemented".

Loading...