FS#7415 - Pacman doesn't check for deps when installing a group

Attached to Project: Pacman
Opened by Alex Heck (nesl247) - Monday, 11 June 2007, 04:27 GMT
Last edited by Xavier (shining) - Sunday, 27 January 2008, 21:08 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.0.4
Due in Version 3.1.2
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info: I created ebuilds for gnome-2.19. And this is where the problem started.

In gnome 2.19, control-center is renamed to gnome-control-center. In order to make the group gnome pull gnome-control-center, I put replaces/conflicts/provides control-center in the gnome-control-center PKGBUILD.

However, when installing the package (to make sure it is installed instead of control-center), and then running pacman -S gnome, gnome-control-center AND control-center are pulled in.

Once gnome-control-center is installed, control-center is attempted to be installed, which then states that there is a conflict and that gnome-control-center should be removed (yes/no to remove).

Pacman should see that gnome-control-center is replacing control-center, and not pull in control-center when you run pacman -S.

Steps to Reproduce:
Closed by  Xavier (shining)
Sunday, 27 January 2008, 21:08 GMT
Reason for closing:  Fixed
Additional comments about closing:  pacman should now choose the provider by default. If there is still a problem, use --ignore or IgnorePkg.
Comment by Alex Heck (nesl247) - Monday, 11 June 2007, 04:29 GMT
Oops, forgot to state:

[gnome]
Server = http://arch.nesl247.org/gnome/i686

PKGBUILD and such for gnome-control-center: http://arch.nesl247.org/gnome/i686/gnome-control-center/
Comment by Cory Grunden (vipernicus) - Monday, 11 June 2007, 04:35 GMT
I can report that I have this issue using this repo.
Comment by Xavier (shining) - Sunday, 17 June 2007, 15:18 GMT
I find your report a bit confusing.
Maybe copy/pasting the pacman commands you run and their output would help clearing the confusion.
(Also, the repo didn't work for me, I got a: 500 Internal Server Error)
Comment by Cory Grunden (vipernicus) - Sunday, 17 June 2007, 15:39 GMT
He's moved it to:
http://arch.nesl247.org/gnome-devel/i686/gnome-control-center/

The issue was:
pacman -S gnome (with his overlay on top)
would pull in both gnome groups, and would attempt to pull in control-center and gnome-control-center, which was causing a conflict. In the the meantime, he's made it gnome-devel to keep this from happening.

The issue is that in the gnome-control-center PKGBUILD:
replaces=('control-center')
provides=('control-center')
conflicts=('control-center')

control-center shouldn't have been pulled in with pacman -S gnome, since it was defined in the PKGBUILD to be replaced by gnome-control-center.
Comment by Xavier (shining) - Sunday, 17 June 2007, 16:14 GMT
Ah, the conflicts is important here, it's in the PKGBUILD but not in the database, see :
LANG=C pacman -Si 'gnome-control-center' |grep Conflict
Conflicts With : None

Might be similar to this bug :
http://bugs.archlinux.org/task/7338
Comment by Alex Heck (nesl247) - Sunday, 17 June 2007, 16:41 GMT
I think that is the bug. Why isn't it fixed yet.. Seems like a really serious bug.
Comment by Dan McGee (toofishes) - Sunday, 17 June 2007, 16:44 GMT
Can we get the commands used to generate the sync DB? Was repo-add being used, or gensync?
Comment by Alex Heck (nesl247) - Sunday, 17 June 2007, 16:49 GMT
repo-add was used.
Comment by Xavier (shining) - Sunday, 17 June 2007, 17:06 GMT
I found the problem, see bug #7338 .
Comment by Alex Heck (nesl247) - Sunday, 17 June 2007, 17:34 GMT
Was it definitely the fact that conflicts isn't there that gnome wanted to pull in both control-center and gnome-control-center?
Comment by Xavier (shining) - Sunday, 17 June 2007, 19:06 GMT
I believe so, or at least, it won't try to pull them both,
but maybe it will choose the wrong one.

If both conflict with each other, and both belongs to the gnome group, when you pacman -S gnome,
it'll apparently ask you to remove the one installed, and install the other.
For example, if you've gnome-control-center installed, pacman -S gnome will ask you
to remove it, because it conflicts with control-center.
If you answer no, it'll fail, saying control-center conflicts with gnome-control-center.

That might not be ideal though, maybe it should keep the package that replaces the other in both case.

I saw this behavior from a pactest, but maybe I didn't manage to reproduce exactly the same situation,
so it would be interesting to fix that repo, and see if that's indeed what happens.
Comment by Alex Heck (nesl247) - Sunday, 17 June 2007, 19:10 GMT
Pacman should definitely use gnome-control-center in this case. As it has provides=('control-center') and replaces=('control-center'). Which SHOULD mean replace control-center if it's used, and use it over control-center when building deps. The problem is I don't think pacman looks for packages with both, and assumes to use that package, over the other.
Comment by Dan McGee (toofishes) - Monday, 18 June 2007, 00:27 GMT
7338 is now fixed- do we have an outstanding issue above as Chantry has pointed out?
Comment by Alex Heck (nesl247) - Monday, 18 June 2007, 01:30 GMT
I don't know, someone would have to try my repo by just adding it, and then pacman -Syu. As vipernicus isn't using arch right now, and he was the person who told me the issue.
Comment by Dan McGee (toofishes) - Monday, 18 June 2007, 01:56 GMT
Anyone willing to try this out with pacman 3.0.5 (hitting your mirrors either now or soon)?
Comment by Alex Heck (nesl247) - Friday, 22 June 2007, 15:51 GMT
I tried it out. And I still have the issue. gnome-control-center got installed, then I did pacman -S gnome, and it tried to pull in control-center. So I let it replace, and it went on... Soo.
Comment by Xavier (shining) - Friday, 22 June 2007, 16:09 GMT
And if you pacman -S gnome again, it want to pull gnome-control-center back, right ?
Comment by Alex Heck (nesl247) - Friday, 22 June 2007, 16:12 GMT
right, and then it succeeded fine if I recall.
Comment by Xavier (shining) - Friday, 22 June 2007, 16:22 GMT
Attaching a pactest which should reproduce this bug.
   sync022.py (0.5 KiB)
Comment by Not Important (pholie) - Wednesday, 27 June 2007, 21:24 GMT
it seems like my problem is the same. i tried to install compiz-fusion group from the compiz-fusion repo:

# pacman -S compiz-fusion
:: group compiz-fusion:
ccsm-git compiz-bcop-git compiz-fusion-plugins-extra-git compiz-fusion-plugins-main-git compiz-fusion-plugins-unsupported-git compiz-icon-git compizconfig-python-git
emerald-git emerald-themes-git libcompizconfig-git
:: Install whole content? [Y/n]
resolving dependencies... done.
looking for inter-conflicts...
:: cairo conflicts with cairo-lcd. Remove cairo-lcd? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: cairo: conflicts with cairo-lcd


particularly, the package compiz-git depends on cairo.

But cairo-lcd (already installed) provides and conflicts with cairo. So why it still wants to install the original cairo package?
Comment by Xavier (shining) - Wednesday, 27 June 2007, 21:49 GMT
That looks like a different problem, you're not trying to install two conflicting package in the same time, only one of them.
Please report a new bug :)
And pacman should already take care of this case, so more informations would help.
For example, attach output of "pacman -S compiz-fusion --debug" in that new bug report,
and also output of pacman -Si (or -Qi) for the relevant packages (eg compiz-git, cairo and cairo-lcd).
Comment by Not Important (pholie) - Wednesday, 27 June 2007, 23:16 GMT
Here it goes: http://bugs.archlinux.org/task/7524
But actually, after running --debug I found out that the reason of this conflict is that not even the compiz-git depends on cairo but also one of its dependencies depends on a cairo>=1.4.6-2, the condicion which was not fulfilled.

So it seems maybe it's not a bug but it's only pacman not being too descriptive on what happens...
Comment by Dan McGee (toofishes) - Friday, 28 September 2007, 17:54 GMT
Can this be closed?
Comment by Xavier (shining) - Friday, 28 September 2007, 18:21 GMT
I see at least 3 possibilities :

1) reject the bug with the following reason :
installing a group containing two conflicting targets -> undefined behavior

Same if trying to install two conflicting targets directly, like :
pacman -S control-center gnome-control-center

2) extend the "replaces" meaning in pacman code, and use it as a hint for resolving package conflicts

3) make pacman more interactive : ask which package should be installed in this case : control-center or gnome-control-center
Comment by Roman Kyrylych (Romashka) - Saturday, 29 September 2007, 15:10 GMT
I think packagers shouldn't allow two conflicting targets in a group, so #1 sounds OK.
Comment by Xavier (shining) - Saturday, 29 September 2007, 15:24 GMT
Indeed, but note that a particular group can exist on different repos. Which is exactly what happened here. The two conflicting packages were not on the same repo.

And this case of having a group present on different repos is going to happen again.
It happened again when gnome 2.19 was in that gnome repo. And still the same now that gnome 2.20 is in testing.
Comment by Dan McGee (toofishes) - Wednesday, 16 January 2008, 05:28 GMT
Xavier, do you know the status on this?

Your sync022.py test above passes with current maint branch. Is there anything else to worry about here that isn't covered in bug 7524?
Comment by Xavier (shining) - Wednesday, 16 January 2008, 07:52 GMT
> 2) extend the "replaces" meaning in pacman code, and use it as a hint for resolving package conflicts

The problem with that sync022 pactest is that replaces and provides are used together.
And pacman uses "provides" for resolving the conflict, not "replaces".

But well, thinking about it again, I guess provides and replaces are generally used together, so it should
work fine most of the time.

And otherwise, IgnorePkg could always be used.

So maybe we don't really have to worry about this anymore, unless some new reports come in.

Loading...