FS#8763 - syncing a provide is not intuitive

Attached to Project: Pacman
Opened by Scott H (stonecrest) - Monday, 26 November 2007, 05:02 GMT
Last edited by Xavier (shining) - Monday, 21 January 2008, 12:18 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Xavier (shining)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version git
Due in Version 3.1.1
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


I did a 'pacman -S scrollkeeper' recently and was unexpectedly asked about the 'rarian' package. It took me a bit to figure out that rarian provides scrollkeeper. So here are two thoughts:

1. Give a warning to the user. Something like "Warning: rarian package provides scrollkeeper" or some such.

2. Don't auto-resolve? This is up for discussion. But it's particularly a question if you were to pacman -S foo and there are multiple packages that provide foo. I think that pacman currently resolves to the first provides package it finds.
This task depends upon

Closed by  Xavier (shining)
Monday, 21 January 2008, 12:18 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in 3.1.1
Comment by Aaron Griffin (phrakture) - Friday, 30 November 2007, 17:18 GMT
I'd be fine with #1, something more to the effect of "No package found, but X provides Y"
Comment by Nagy Gabor (combo) - Wednesday, 12 December 2007, 16:02 GMT
This is mainly a %REPLACES% problem imho. Currently that is used with -Su only, however it would be useful with -S too.
If foo replaces bar, but foo doesn't provide bar (because foo is an other concept), and if you do a "pacman -S bar", you will simply won't be informed about the fact you should change your favourite bar package to foo.
Comment by Xavier (shining) - Tuesday, 01 January 2008, 20:40 GMT
Nagy, I think that's quite off topic, and it goes a bit in the opposite direction of what stonecrest is asking : not confusing the user by installing a package he didn't request.
And anyway, I don't think your example makes much sense. When a package replaces another, it usually provides it as well, otherwise it wouldn't really be a replacement, and it could break dependencies. And besides, the deprecated package has no reason to stay and is usually deleted from the repos, so you can't -S it.

Now about the report :
I'm fine with 1, but I'm afraid it's not possible for 3.1, which is in string freeze, right?
I could be fine with 2 too, but in this case, the user needs an easy way to get the list of providers.
Comment by Nagy Gabor (combo) - Wednesday, 02 January 2008, 14:54 GMT
Xavier, we probably interpret -S differently, in my definition it is primarily a package _upgrade_ (not package adding); and %REPLACES% can define tricky upgrades.

Let me go back to stonecrest's example:
He has scrollkeeper installed, which is officially replaced by rarian.

Case 1. He wants to _upgrade_ scrollkeeper, but now that is a provision only. If rarian doesn't conflict with scrollkeeper (can happen), the old scrollkeeper won't be removed so will become a spam.

You said, "not confusing the user by installing a package he didn't request.". I agree here, so I suggest this: "rarian replaces scrollkeeper. Do you want to replace scrollkeeper with rarian? [Y/n]", so do the same as with -Su.

"And anyway, I don't think your example makes much sense."
Imagine the following example: Your distro makes a radical change, for example foo=dpkg and bar=pacman (I know, that this is a very bad example, replace pacman; but I hope, you understand what I want to say); that's why I wrote foo is an other concept, so that is not "compatible" with bar, but an _alternative_.

Case 2. If user wants to _add_ scrollkeeper then I also vote for no-autoresolve, just give a warning, as stonecrest suggested.
Comment by Scott H (stonecrest) - Wednesday, 02 January 2008, 18:08 GMT
Actually, my example was case 2. I wasn't upgrading scrollkeeper, I was installing it. And indeed, I think installing a provide is _MUCH_ more common than upgrading one. Because when you upgrade, you typically just do a -Su; how often do you do a -S with the package name to upgrade it?

I don't know that the two cases necessarily have to be handled differently, I'd personally be okay with the same warning in both cases.
Comment by Xavier (shining) - Wednesday, 02 January 2008, 18:57 GMT
I agree with stonecrest.
Comment by Xavier (shining) - Sunday, 06 January 2008, 10:41 GMT
Attaching a patch that does #1 when there is just one provider, and #2 when there are multiple providers.
Comment by Dan McGee (toofishes) - Sunday, 06 January 2008, 15:42 GMT
Due to the string change, this has to wait until 3.1.1, but I would guess it is good to apply.