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#6057 - impossible to remove package+dependencies, when it is required

Attached to Project: Pacman
Opened by Roman Kyrylych (Romashka) - Friday, 22 December 2006, 19:41 GMT
Last edited by Roman Kyrylych (Romashka) - Thursday, 15 November 2007, 11:52 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity High
Priority Normal
Reported Version 2.9.8
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

It is impossible to remove package with dependencies at once, when it is required by another package(s).
This is valid for both pacman v2 and v3.
This task depends upon

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Roman Kyrylych (Romashka)
Thursday, 15 November 2007, 11:52 GMT
Reason for closing:  Fixed
Comment by Roman Kyrylych (Romashka) - Friday, 22 December 2006, 19:41 GMT
In pacman 2.9.8:


[rk@home ~]$ sudo pacman -S taglib-rcc

Remove: taglib

Targets: enca-1.9-2 librcd-0.1.8-3 librcc-0.2.3-4 taglib-rcc-1.4-3

Total Package Size: 0.6 MB

Proceed with upgrade? [Y/n]

checking package integrity... done.
removing taglib... done.
loading package data... done.
checking for file conflicts... done.
installing enca... done.
installing librcd... done.
installing librcc... done.
-- Don't forget to install gtk or/and gtk2 packages to enable librcc
gui features
-- Also you may change /usr/bin/rcc-config symlink to switch between
gtk and gtk2 (rcc-gtk-config and rcc-gtk2-config)
installing taglib-rcc... done.
[rk@home ~]$
[rk@home ~]$
[rk@home ~]$
[rk@home ~]$ sudo pacman -S taglib
:: taglib conflicts with taglib-rcc. Remove taglib-rcc? [Y/n]

Remove: taglib-rcc

Targets: taglib-1.4-2

Total Package Size: 0.2 MB

Proceed with upgrade? [Y/n]

checking package integrity... done.
error: this will break the following dependencies:
taglib-rcc: is required by audacious-plugins
taglib-rcc: is required by gimmix
taglib-rcc: is required by gstreamer0.10-taglib
taglib-rcc: is required by sound-juicer

[rk@home ~]$
[rk@home ~]$
[rk@home ~]$
[rk@home ~]$ sudo pacman -Rs taglib-rcc
error: this will break the following dependencies:
taglib-rcc: is required by audacious-plugins
taglib-rcc: is required by gimmix
taglib-rcc: is required by gstreamer0.10-taglib
taglib-rcc: is required by sound-juicer

[rk@home ~]$
[rk@home ~]$ sudo pacman -Rsc taglib-rcc

Targets: audacious-docklet audacious sound-juicer gstreamer0.10-gnomevfs
musicbrainz libcdio libcddb gstreamer0.10-taglib gimmix
audacious-plugins audacious-player taglib-rcc librcc librcd enca

Do you want to remove these packages? [Y/n] n

[rk@home ~]$
[rk@home ~]$ sudo pacman -Rsd taglib-rcc
removing taglib-rcc... done.
[rk@home ~]$
Comment by Roman Kyrylych (Romashka) - Friday, 22 December 2006, 19:45 GMT
In pacman 3.0 beta:

[rk@home ~]$ sudo pacman3 -S taglib-rcc
resolving dependencies... done.
looking for inter-conflicts...
:: taglib-rcc conflicts with taglib. Remove taglib? [Y/n]
done.

Remove: taglib

Targets: enca-1.9-2 librcd-0.1.8-3 librcc-0.2.3-4 taglib-rcc-1.4-3

Total Package Size: 0,6 MB

Proceed with installation? [Y/n]
checking package integrity... done.
checking for file conflicts (4/4) [#######################] 100%
(1/4) installing enca [#######################] 100%
(2/4) installing librcd [#######################] 100%
(3/4) installing librcc [#######################] 100%
-- Don't forget to install gtk or/and gtk2 packages to enable librcc
gui features
-- Also you may change /usr/bin/rcc-config symlink to switch between
gtk and gtk2 (rcc-gtk-config and rcc-gtk2-config)
(4/4) installing taglib-rcc [#######################] 100%
[rk@home ~]$
[rk@home ~]$
[rk@home ~]$
[rk@home ~]$ sudo pacman3 -S taglib
resolving dependencies... done.
looking for inter-conflicts...
:: taglib conflicts with taglib-rcc. Remove taglib-rcc? [Y/n]
done.
error: failed to prepare transaction (could not satisfy dependencies)
:: taglib-rcc is required by audacious-plugins
:: taglib-rcc is required by gimmix
:: taglib-rcc is required by gstreamer0.10-taglib
:: taglib-rcc is required by sound-juicer

[rk@home ~]$ sudo pacman3 -Rs taglib-rcc
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: taglib-rcc is required by audacious-plugins
:: taglib-rcc is required by gimmix
:: taglib-rcc is required by gstreamer0.10-taglib
:: taglib-rcc is required by sound-juicer

[rk@home ~]$ sudo pacman3 -Rsc taglib-rcc
checking dependencies... done.

Targets: audacious-docklet audacious sound-juicer gstreamer0.10-gnomevfs
musicbrainz libcdio libcddb gstreamer0.10-taglib gimmix
audacious-plugins audacious-player taglib-rcc librcc librcd enca db
libxml2 bash zlib gcc

Do you want to remove these packages? [Y/n] n

[rk@home ~]$
[rk@home ~]$ sudo pacman3 -Rsd taglib-rcc

Targets: taglib-rcc

Do you want to remove these packages? [Y/n]

(1/1) removing taglib-rcc [#######################] 100%
[rk@home ~]$
Comment by Roman Kyrylych (Romashka) - Friday, 22 December 2006, 19:47 GMT
How it should be:

[rk@home ~]$ sudo pacman3 -Rsd taglib-rcc

Remove: taglib-rcc

Targets: enca-1.9-2 librcd-0.1.8-3 librcc-0.2.3-4 taglib-rcc-1.4-3

Do you want to remove these packages? [Y/n]
Comment by tardo (tardo) - Saturday, 23 December 2006, 00:44 GMT
Slightly off topic...

In your third comment, pacman3 tries to remove bash/gcc/zlib. I don't know how lean your system is, but zlib is required by file and linux-info AND pacman itself. Removing zlib (and gcc/bash) IMO is a bug. This happened to me once in my chrooted environment but I can't seem to reproduce it.
Comment by Roman Kyrylych (Romashka) - Saturday, 23 December 2006, 13:50 GMT
Yes, this is a bug.
I've also encountered this with pacman2:
pacman -Rs mc-colorer wanted to remove mc-colorer, colorer and _gcc_ :D
I didn't notice this and it started to remove gcc, so I had to reinstall gcc and then couldn't reproduce this again.
Similar problem - with pacman3. See http://bugs.archlinux.org/?getfile=884.
Comment by Roman Kyrylych (Romashka) - Thursday, 22 March 2007, 13:48 GMT
Status of http://bugs.archlinux.org/task/6057#comment13217 ?
EDIT: OK, I'll check this by myself after I'll install pacman3 here. :-P
Comment by Roman Kyrylych (Romashka) - Saturday, 07 April 2007, 14:54 GMT
still valid
Comment by Roman Kyrylych (Romashka) - Saturday, 07 April 2007, 14:58 GMT Comment by Roman Kyrylych (Romashka) - Saturday, 07 April 2007, 15:01 GMT
here are two issues:
1st - unable to remove package with dependencies when it's required
2nd - taglib could be replaced with taglib-rcc but reverse is not true (I guess this is because taglib-rcc _provides_ taglib, so something in handling dependencies+provides is not good)
Comment by Roman Kyrylych (Romashka) - Saturday, 07 April 2007, 15:10 GMT
3rd bug here! Compare:

[root@home /]# pacman -S taglib
resolving dependencies... done.
looking for inter-conflicts...
:: taglib conflicts with taglib-rcc. Remove taglib-rcc? [Y/n]
done.
error: failed to prepare transaction (could not satisfy dependencies)
:: taglib-rcc requires audacious-plugins
:: taglib-rcc requires gimmix
:: taglib-rcc requires sound-juicer

and

[root@home /]# pacman -Rs taglib-rcc
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: taglib-rcc is required by audacious-plugins
:: taglib-rcc is required by gimmix
:: taglib-rcc is required by sound-juicer

It should be "is required" in the first case too. :-D

Note that it is regression since beta versions of pacman 3 (see output of pacman 2 and pacman 3 beta above).
Comment by Xavier (shining) - Saturday, 09 June 2007, 16:43 GMT
Attaching a patch supposed to fix only the output problem mentioned in last comment.

Otherwise, I believe I understand what is wrong in the code, but I don't know how to correctly fix it.
When you pacman -S taglib, taglib-rcc has to be removed because of the conflict.
lib/libalpm/sync.c , line 685, there is a call to _alpm_checkdeps function.
This function (lib/libalpm/deps.c lines 370-420) will check which packages will be broken by the remove of taglib-rcc,
ie packages which are required by taglib-rcc : audacious-plugins, gimmix, sound-juicer, and return these.
Then in sync.c, lines >685, it looks if there are packages in the target list (here : taglib) which provides taglib (dependency needed by audacious-plugins, gimmix, sound-juicer)
But taglib doesn't _provide_ taglib, taglib _is_ taglib...
In the other direction, when pacman -S taglib-rcc, taglib-rcc provides taglib, so it works.

To sum up, the code in lib/libalpm/sync.c (lines 680-720), and lib/libalpm/deps.c (lines 370-420), looks badly broken.
These two parts seem to do a duplicate job, and do it wrong.
Comment by Dan McGee (toofishes) - Monday, 11 June 2007, 03:20 GMT
This should be fixed in GIT as of today. sync900 and sync901 were pactest cases written for the bug, and both pass.
Comment by Xavier (shining) - Monday, 09 July 2007, 20:58 GMT
I'm looking back at this, and I remember there was something I didn't understand in the report. There were several issues mentioned :
2nd - taglib could be replaced with taglib-rcc but reverse is not true (I guess this is because taglib-rcc _provides_ taglib, so something in handling dependencies+provides is not good)
3rd bug (output issue)

both these should have been fixed by the following commit :
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=8588b4823b579bc41909734f5a13a420d64487d6

The one I didn't understand is this one :
1st - unable to remove package with dependencies when it's required

As far as I can tell, there is no issue there, you _have_ to use the c(ascade) pacman option
if you want to remove the packages that depend on the one you're removing.
Otherwise these packages would be broken (d option allows you to break packages if you like).
Anyway, this is already the behavior of both pacman2 and pacman3 according to the output in this bug report,
so it's confusing.
It looks like pacman2 and pacman3 already had the same and correct behavior for removing packages.
Comment by Roman Kyrylych (Romashka) - Wednesday, 11 July 2007, 15:17 GMT
> As far as I can tell, there is no issue there, you _have_ to use the c(ascade) pacman option
> if you want to remove the packages that depend on the one you're removing.
> Otherwise these packages would be broken (d option allows you to break packages if you like).

OK, but then consider this as a feature request for the following:

[rk@home ~]$ sudo pacman3 -Rsd taglib-rcc
Remove: taglib-rcc
Targets: enca-1.9-2 librcd-0.1.8-3 librcc-0.2.3-4 taglib-rcc-1.4-3
Do you want to remove these packages? [Y/n]

This acts like -Rd but also removes all dependencies (not required by others of course) of package that is going to be removed.
Comment by Roman Kyrylych (Romashka) - Wednesday, 11 July 2007, 15:21 GMT
Also, found the following inconsistency in pacman 3.0.5-2:

[root@server ~]# pacman -Rs taglib
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: taglib is required by thunar-media-tags-plugin
:: taglib is required by xfmedia
:: taglib is required by audacious-plugins

[root@server ~]# pacman -Rsd taglib

Targets: taglib

Do you want to remove these packages? [Y/n] n

[root@server ~]# pacman -Rd taglib
(1/1) removing taglib [#####################] 100%

Sure, -Rsd is meaningless combination now, but why the hell it works different than -Rs and -Rd ? :)
I think it would be very nice if -Rd asked confirmation first.

Sorry, cannot check the git version now. Someone please check if this is different with git now.
Comment by Xavier (shining) - Wednesday, 11 July 2007, 18:35 GMT
-Rsd is just like -Rs, except it doesn't check deps (nodeps), so you won't have these 3 "required by" errors.

-Rs(d) asks you for confirmation, because of the _potentials_ packages added to the targets for removal.
So in this particular case when no packages were added, it does look a bit weird, but in many cases where new targets are added, it's useful.

With only -Rd, no new targets are ever pulled by pacman, it just removes the ones you asked, so no confirmation there (like with -S).
Comment by Roman Kyrylych (Romashka) - Thursday, 12 July 2007, 10:56 GMT
Thanks for clarification

> -Rsd is just like -Rs, except it doesn't check deps (nodeps), so you won't have these 3 "required by" errors.
This behaviour is useless. It does not differ much from -Rd except for a confirmation.
I'd like to change this behaviour to something more useful (as described in my post above).
Comment by Xavier (shining) - Thursday, 12 July 2007, 11:52 GMT
Sorry, I was wrong earlier, I misread the code.
Indeed -Rsd combination is totally useless, since d removes the s effect, so it'll never do a recursive removal when d is used.
So either -Rsd should behave just like -Rd (no ask for confirmation), or it should behave like you described above, ie make d (nodeps) not skip s (recursive).

Here is a patch for the second option (it looks bigger than it actually is, the second half is only indenting fix, because the recursive removal part
was moved outside of the if block).

From a8d4c8587ac469ca1c811216fe070ffd9390b4b1 Mon Sep 17 00:00:00 2001
From: Chantry Xavier <shiningxc@gmail.com>
Date: Thu, 12 Jul 2007 13:49:23 +0200
Subject: [PATCH] libalpm/remove.c : Rsd combination.

Currently the d (nodeps) option skips the s (recursive) part,
rendering the Rsd combination totally useless.
This patch makes a recursive removal still possible using the nodeps option,
as Romashka asked there :
http://bugs.archlinux.org/task/6057#comment17784

Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
---
lib/libalpm/remove.c | 32 ++++++++++++++++++--------------
1 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/lib/libalpm/remove.c b/lib/libalpm/remove.c
index 57e452d..9b7204d 100644
--- a/lib/libalpm/remove.c
+++ b/lib/libalpm/remove.c
@@ -97,9 +97,13 @@ int _alpm_remove_prepare(pmtrans_t *trans, pmdb_t *db, alpm_list_t **data)
ASSERT(db != NULL, RET_ERR(PM_ERR_DB_NULL, -1));
ASSERT(trans != NULL, RET_ERR(PM_ERR_TRANS_NULL, -1));

- if(!(trans->flags & (PM_TRANS_FLAG_NODEPS)) && (trans->type != PM_TRANS_TYPE_UPGRADE)) {
- EVENT(trans, PM_TRANS_EVT_CHECKDEPS_START, NULL, NULL);
+ if(trans->type == PM_TRANS_TYPE_UPGRADE) {
+ return(0);
+ }

+ EVENT(trans, PM_TRANS_EVT_CHECKDEPS_START, NULL, NULL);
+
+ if(!(trans->flags & PM_TRANS_FLAG_NODEPS)) {
_alpm_log(PM_LOG_DEBUG, "looking for unsatisfied dependencies");
lp = _alpm_checkdeps(db, trans->type, trans->packages);
if(lp != NULL) {
@@ -130,21 +134,21 @@ int _alpm_remove_prepare(pmtrans_t *trans, pmdb_t *db, alpm_list_t **data)
RET_ERR(PM_ERR_UNSATISFIED_DEPS, -1);
}
}
+ }

- if(trans->flags & PM_TRANS_FLAG_RECURSE) {
- _alpm_log(PM_LOG_DEBUG, "finding removable dependencies");
- trans->packages = _alpm_removedeps(db, trans->packages);
- }
+ if(trans->flags & PM_TRANS_FLAG_RECURSE) {
+ _alpm_log(PM_LOG_DEBUG, "finding removable dependencies");
+ trans->packages = _alpm_removedeps(db, trans->packages);
+ }

- /* re-order w.r.t. dependencies */
- _alpm_log(PM_LOG_DEBUG, "sorting by dependencies");
- lp = _alpm_sortbydeps(trans->packages, PM_TRANS_TYPE_REMOVE);
- /* free the old alltargs */
- alpm_list_free(trans->packages);
- trans->packages = lp;
+ /* re-order w.r.t. dependencies */
+ _alpm_log(PM_LOG_DEBUG, "sorting by dependencies");
+ lp = _alpm_sortbydeps(trans->packages, PM_TRANS_TYPE_REMOVE);
+ /* free the old alltargs */
+ alpm_list_free(trans->packages);
+ trans->packages = lp;

- EVENT(trans, PM_TRANS_EVT_CHECKDEPS_DONE, NULL, NULL);
- }
+ EVENT(trans, PM_TRANS_EVT_CHECKDEPS_DONE, NULL, NULL);

return(0);
}
--
1.5.2.2
Comment by Dan McGee (toofishes) - Friday, 13 July 2007, 14:16 GMT
I applied the above patch in my GIT tree. Does the output error patch from above (in checkdeps) still need to be applied? The current one as it stands fails to apply.
Comment by Xavier (shining) - Friday, 13 July 2007, 18:25 GMT
No, that output patch shouldn't be applied.
As I said here :
http://bugs.archlinux.org/task/6057#comment17752

I fixed it later in another (imo better) way,
which made it into GIT a while ago.
Comment by Aaron Griffin (phrakture) - Wednesday, 14 November 2007, 22:52 GMT
Man I hate when these bug reports become 9 other different bugs in the comments...

I don't *think* this original bug was fixed at all, but it appears to be 'requireby' related - can someone test this with Dan's new requiredby removal changes?
Comment by Dan McGee (toofishes) - Thursday, 15 November 2007, 06:10 GMT
Xavier or Roman, any input here on the status of this bug? If you could test with pacman-git-20071114 (first version with requiredby changes) it would be appreciated.
Comment by Xavier (shining) - Thursday, 15 November 2007, 10:14 GMT
I made a sum up there : http://bugs.archlinux.org/task/6057#comment17752
The second and third issue were already fixed, and the first one wasn't a real issue, but led to a new behavior of -Rsd option.

Removing requiredby mostly affects the second issue, for which there are pactests : sync900 and sync901.
They already worked fine, and still do after the last changes in git.
Comment by Xavier (shining) - Thursday, 15 November 2007, 10:26 GMT
Just in case, I checked again with last git all the steps described by Romashka, and everything still looks fine to me.
Comment by Roman Kyrylych (Romashka) - Thursday, 15 November 2007, 11:23 GMT
#1 is implemented with Xavier's patch. Thanks Xavier!
#2 & #3 are fixed.

# pacman -Qi taglib | grep Required
Required By : sound-juicer

# pacman -Sy taglib-rcc
:: Synchronizing package databases...
core 23,1K 30,5K/s 00:00:01 [#####################] 100%
extra 314,8K 15,7K/s 00:00:20 [#####################] 100%
community 326,5K 15,2K/s 00:00:21 [#####################] 100%
resolving dependencies... done.
looking for inter-conflicts... :: taglib-rcc conflicts with taglib. Remove taglib? [Y/n]
done.

Remove: taglib

Total Removed Size: 0,65 MB

Targets: enca-1.9-2 librcd-0.1.8-3 librcc-0.2.3-6 taglib-rcc-1.4-4

Total Download Size: 0,62 MB
Total Installed Size: 2,06 MB

Proceed with installation? [Y/n]
:: Retrieving packages from community...
enca-1.9-2 165,7K 14,9K/s 00:00:11 [#####################] 100%
librcd-0.1.8-3 108,7K 35,1K/s 00:00:03 [#####################] 100%
librcc-0.2.3-6 175,6K 25,4K/s 00:00:07 [#####################] 100%
taglib-rcc-1.4-4 188,7K 23,6K/s 00:00:08 [#####################] 100%
checking package integrity... done.
(4/4) checking for file conflicts [#####################] 100%
(1/4) installing enca [#####################] 100%
(2/4) installing librcd [#####################] 100%
(3/4) installing librcc [#####################] 100%
-- Don't forget to install gtk or/and gtk2 packages to enable librcc
gui features
-- Also you may change /usr/bin/rcc-config symlink to switch between
gtk and gtk2 (rcc-gtk-config and rcc-gtk2-config)
(4/4) installing taglib-rcc [#####################] 100%

# pacman -Qi taglib-rcc | grep Required
Required By : sound-juicer

pacman -R taglib-rcc
loading package data... done.
checking dependencies... error: failed to prepare transaction (could not satisfy dependencies)
:: sound-juicer: requires taglib

# pacman -Rs taglib-rcc
loading package data... done.
checking dependencies... error: failed to prepare transaction (could not satisfy dependencies)
:: sound-juicer: requires taglib

# pacman -Rsc taglib-rcc
loading package data... done.
checking dependencies... done.

Targets: sound-juicer taglib-rcc libcdio librcc libcddb enca librcd

Do you want to remove these packages? [Y/n] n

# pacman -Rsd taglib-rcc
loading package data... done.
checking dependencies... done.

Targets: taglib-rcc librcc enca librcd

Do you want to remove these packages? [Y/n]

(1/4) removing taglib-rcc [#####################] 100%
(2/4) removing librcc [#####################] 100%
(3/4) removing enca [#####################] 100%
(4/4) removing librcd [#####################] 100%
Comment by Roman Kyrylych (Romashka) - Thursday, 15 November 2007, 11:52 GMT
However, I've just saw an issue with replacement. :-P See the last comment on FS#5974.
I'm closing this report now (everything mentioned here is fixed).

Loading...