Arch Linux

If after installing gparted, I reinstall gtkmm, the problem is resolved and gtkmm now knows that it is needed by both gparted and inkscape.

Another bigger issue is the following:
Package 'A' depends on package 'B'.
If I pacman -S 'A' , it will install both 'A' and 'B' as expected.
Later the maintainer of package 'A' updates it and removes the 'B' dependency.
I pacman -Syu and I am updated to latest version of package 'A' which does not depend on 'B'.
I pacman -Qi 'A' and it doesn't depend on 'B'
But pacman -Qe doesn't mention 'B'
and the problem is:
pacman -Qi 'B' still incorrectly says 'B' is needed by 'A'.

I can't reproduce the original problem:
if I've a package pkg2 depending on a package foo both installed on my system,
and so foo is required by pkg2.
If I install package pkg1 also depending on foo, then foo will be required by both pkg1 and pkg2.

Here is a pactest I used :
self.description = "Adds a second requiredby field"

sp = pmpkg("pkg1")
sp.depends = ["foo"]
self.addpkg2db("sync", sp)

lp = pmpkg("foo")
lp.requiredby = ["pkg2"]
self.addpkg2db("local", lp)

lp2 = pmpkg("pkg2")
lp2.depends = ["foo"]
self.addpkg2db("local", lp2)

self.args = "-S %s" % sp.name

self.addrule("PACMAN_RETCODE=0")
self.addrule("PKG_EXIST=pkg1")
self.addrule("PKG_EXIST=pkg2")
self.addrule("PKG_EXIST=foo")
self.addrule("PKG_REQUIREDBY=foo|pkg1")
self.addrule("PKG_REQUIREDBY=foo|pkg2")


I believe the second issue you describe is the one Nagy noticed here :
http://www.archlinux.org/pipermail/pacman-dev/2007-June/008503.html

But his patch for fixing it has been refused, and no other solutions have been proposed.

Ok, so you can ignore everything I said about the original problem.
I thought the problem was caused by missing requiredby in the database, but that's not the case at all.
If I read the report correctly, I would not have make this mistake, because of this :
"If I do 'pacman -Rns gtkmm', pacman will complain as expected that gtkmm is required by inkscape and gparted."

That seemed to indicated the RequiredBy fields of gtkmm were actually correct ?
So what did reinstalling gtmm change ? The order of the package in the RequiredBy field of gtkmm !!
Initially it was :
Required By : gparted inkscape
And after reinstalling gtkmm, it is :
Required By : inkscape gparted

So you'll still get the same problem, only reversed.

The problem was in lib/libalpm/deps.c, checkdeps function, the remove part :
381 for(j = alpm_pkg_get_requiredby(tp); j; j = j->next) {
382 /* Search for 'reqname' in packages for removal */
383 char *reqname = j->data;
384 alpm_list_t *x = NULL;
385 for(x = packages; x; x = x->next) {
386 pmpkg_t *xp = x->data;
387 if(strcmp(reqname, alpm_pkg_get_name(xp)) == 0) {
388 found = 1;
389 break;
390 }
391 }

So it was looking at the package which required gtkmm, starting with the first inkscape.
It found inkscape was already in the targets, so that's ok.
And then a break !!! That should obviously be a continue there, in order to look at the other RequiredBy fields.

Anyway, most of the code in checkdeps was totally broken, and has been rewritten by Nagy.
In particular, that broken remove part of the checkdeps function has been reworked and fixed there :
http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=796cc4e6ed06644081f05c1aff4624a6e11eade3

So this is fixed in pacman git.

About the second issue, about which I said Nagy proposed a patch that had been rejected. It has just recently been merged
as well, so that issue is fixed in pacman git too :
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=f0ea21cffca62c566c5e4d2c540c70fb891b9f4c

So I think this bug report can safely be closed.

Any chance those fixes can be backported to pacman 3.0.x release?

Hi!

I believe I have the issue which corresponds to this bug...

I modified pkgbuild for lyx-1.5.1 - here is part of it:

pkgname=lyx
pkgver=1.5.1
pkgrel=1
pkgdesc="An advanced open-source document processor."
arch=('i686' 'x86_64')
url='http://www.lyx.org'
install=${pkgname}.install
license=('GPL-2')
depends=('qt4' 'tetex' 'python' 'perl' 'imagemagick' 'aspell' 'aiksaurus')
source=(ftp://ftp.lyx.org/pub/lyx/stable/$pkgname-$pkgver.tar.gz
lyx.desktop)

Problem is that when I want to remove qt, pacman does not allow it:
[root@nitai Desktop]# pacman -Rsn qt
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: qt is required by lyx

otoh, pacman shows that lyx does not depend on it:

[root@nitai Desktop]# pacman -Qi lyx
Name : lyx
Version : 1.5.1-1
URL : http://www.lyx.org
License : GPL-2
Groups : None
Provides : None
Depends On : qt4 tetex python perl imagemagick aspell aiksaurus
Removes : None
Required By : None
Conflicts With : None
Installed Size : 29495.89 K
Packager : Arch Linux (http://www.archlinux.org)
Architecture : x86_64
Build Date : Mon Aug 13 07:52:51 2007 UTC
Build Type : Unknown
Install Date : Mon Aug 13 08:02:41 2007 UTC
Install Reason : Explicitly installed
Install Script : Yes
Description : An advanced open-source document processor.

but, info for qt says it is required for lyx:

[root@nitai Desktop]# pacman -Qi qt
Name : qt
Version : 3.3.8-4
URL : http://www.trolltech.com/products/qt/index.html
License : GPL
Groups : None
Provides : None
Depends On : libpng libjpeg libxmu libxcursor libxinerama mesa
libxft libxrandr
Removes : None
Required By : lyx
Conflicts With : None
Installed Size : 30821.89 K
Packager : Pierre Schmitz <pierre@archlinux.de>
Architecture : x86_64
Build Date : Sun Jun 24 17:48:40 2007 UTC
Build Type : Unknown
Install Date : Thu Aug 9 10:30:46 2007 UTC
Install Reason : Explicitly installed
Install Script : Yes
Description : The QT gui toolkit.


Sincerely,
Gour

Indeed, that's the same bug, so it's fixed in git.
In the meantime, you can fix the broken RequiredBy fields by reinstalling the package. Eg pacman -S qt.

Xavier- can you confirm if this is fixed in the pacman-git releases? You are more familiar with the bug than I am.

I am confident all issues mentioned here are fixed. I carefully checked back then that it was fixed,
and the relevant parts of the code haven't changed since.
Besides, there are a few pactests that ensure it still works, especially requiredby004.