Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#7495 - pacman does not check dependencies in all cases

Attached to Project: Pacman
Opened by Hussam Al-Tayeb (hussam) - Saturday, 23 June 2007, 02:08 GMT
Last edited by Aaron Griffin (phrakture) - Friday, 09 November 2007, 08:43 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity High
Priority Normal
Reported Version 3.0.5
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I have inkscape and gparted installed. Both require gtkmm.

If I do 'pacman -Rns gtkmm', pacman will complain as expected that gtkmm is required by inkscape and gparted.

But, if I do 'pacman -Rns inkscape gtkmm' it will remove both inkscape and gtkmm and disregard that gtkmm is required by gparted.

But, if I do 'pacman -Rns gparted gtkmm' it will still complain that gtkmm is required by inkscape.

The problem is that gtkmm was initially installed as a dependency by inkscape but gparted was installed later on. pacman -Qi gparted says "Depends On : parted>=1.8.6 gtkmm" but pacman ignores that because gtkmm was first installed as a dependency for inkscape and not gparted.
This task depends upon

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Aaron Griffin (phrakture)
Friday, 09 November 2007, 08:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in git, Mr shining said so!
Comment by Hussam Al-Tayeb (hussam) - Saturday, 23 June 2007, 02:12 GMT
If after installing gparted, I reinstall gtkmm, the problem is resolved and gtkmm now knows that it is needed by both gparted and inkscape.
Comment by Hussam Al-Tayeb (hussam) - Saturday, 07 July 2007, 06:34 GMT
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'.
Comment by Xavier (shining) - Tuesday, 10 July 2007, 12:16 GMT
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.
Comment by Xavier (shining) - Monday, 16 July 2007, 17:09 GMT
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.
Comment by Hussam Al-Tayeb (hussam) - Tuesday, 17 July 2007, 00:21 GMT
Any chance those fixes can be backported to pacman 3.0.x release?
Comment by Gour (gour) - Tuesday, 14 August 2007, 09:19 GMT
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
Comment by Xavier (shining) - Tuesday, 14 August 2007, 09:28 GMT
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.
Comment by Dan McGee (toofishes) - Friday, 09 November 2007, 04:20 GMT
Xavier- can you confirm if this is fixed in the pacman-git releases? You are more familiar with the bug than I am.
Comment by Xavier (shining) - Friday, 09 November 2007, 07:42 GMT
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.

Loading...