Removing conflicting packages

karol · 2011-04-07 17:00:32

[karol@black ~]$ sudo pacman -S mplayer2
resolving dependencies...
looking for inter-conflicts...
:: mplayer2 and mplayer are in conflict. Remove mplayer? [y/N]

pacman removes just mplayer and leaves all the 'dangling' dependencies - packages that were needed by mplayer, but are not needed by mplayer2. Can this behavior be changed to 'pacman -Rns foo'? Is there such an option in pacman or are users expected to deal with this manually?

litemotiv · 2011-04-07 17:28:20

Good one, i think this would be best reported on flyspray or the mailinglist.

JokerBoy · 2011-04-07 18:25:11

That is why `pacman -Qdt` exist.

pacman -Rsn `pacman -Qqdt`

Last edited by JokerBoy (2011-04-07 18:26:11)

stqn · 2011-04-07 19:29:52

pacman -Qdt is not the greatest solution as long as we can't link optional dependencies to their "parent" package... That is, if you install optional dependencies with --asdeps.

falconindy · 2011-04-07 23:20:37

karol wrote:

[karol@black ~]$ sudo pacman -S mplayer2
resolving dependencies...
looking for inter-conflicts...
:: mplayer2 and mplayer are in conflict. Remove mplayer? [y/N]
pacman removes just mplayer and leaves all the 'dangling' dependencies - packages that were needed by mplayer, but are not needed by mplayer2. Can this behavior be changed to 'pacman -Rns foo'? Is there such an option in pacman or are users expected to deal with this manually?

I'm thinking it's for the best that you're expected to deal with this manually. If you want the behavior of pacman -Rsn mplayer, then do that instead of letting pacman remove just mplayer on the conflict.

karol · 2011-04-08 10:44:07

falconindy wrote:

karol wrote:
[karol@black ~]$ sudo pacman -S mplayer2
resolving dependencies...
looking for inter-conflicts...
:: mplayer2 and mplayer are in conflict. Remove mplayer? [y/N]
pacman removes just mplayer and leaves all the 'dangling' dependencies - packages that were needed by mplayer, but are not needed by mplayer2. Can this behavior be changed to 'pacman -Rns foo'? Is there such an option in pacman or are users expected to deal with this manually?
I'm thinking it's for the best that you're expected to deal with this manually. If you want the behavior of pacman -Rsn mplayer, then do that instead of letting pacman remove just mplayer on the conflict.

The question is why would you want to keep dangling dependencies? What's the benefit of keeping things as they are now?

ngoonee · 2011-04-08 10:48:52

karol wrote:

falconindy wrote:
karol wrote:
[karol@black ~]$ sudo pacman -S mplayer2
resolving dependencies...
looking for inter-conflicts...
:: mplayer2 and mplayer are in conflict. Remove mplayer? [y/N]
pacman removes just mplayer and leaves all the 'dangling' dependencies - packages that were needed by mplayer, but are not needed by mplayer2. Can this behavior be changed to 'pacman -Rns foo'? Is there such an option in pacman or are users expected to deal with this manually?
I'm thinking it's for the best that you're expected to deal with this manually. If you want the behavior of pacman -Rsn mplayer, then do that instead of letting pacman remove just mplayer on the conflict.
The question is why would you want to keep dangling dependencies? What's the benefit of keeping things as they are now?

*Not* removing something that the user has not specified he wants removed.

Each command to pacman 'means' something. This is for the same reason that pacman -R foo doesn't remove foo's dependencies, because -R just means "please remove this package". -Rns means "please remove this package and its unused dependencies.

In the case of pacman -S bar, where bar replaces foo (but changes dependencies), there's ambiguity as to whether the user intends pacman -R or pacman -Rns, so pacman errs on the safe side.

Or, seen differently, if you want the dependency removed you're gonna have to specify that. -S does not. Perhaps you COULD request additional options to -S which would do what you want (doubt it'd have much uptake though).

litemotiv · 2011-04-08 11:11:00

ngoonee wrote:

*Not* removing something that the user has not specified he wants removed.
Each command to pacman 'means' something. This is for the same reason that pacman -R foo doesn't remove foo's dependencies, because -R just means "please remove this package". -Rns means "please remove this package and its unused dependencies.
In the case of pacman -S bar, where bar replaces foo (but changes dependencies), there's ambiguity as to whether the user intends pacman -R or pacman -Rns, so pacman errs on the safe side.
Or, seen differently, if you want the dependency removed you're gonna have to specify that. -S does not. Perhaps you COULD request additional options to -S which would do what you want (doubt it'd have much uptake though).

Agreed, but it might not be a bad idea to at least notify the user that any leftover dependencies won't be removed. It is sort of counterintuitive that during an upgrade action that is designed to replace packages, you need to actively cancel the running action, remove a to-be-replaced package with a different command and then re-run the update, unless you want to be stuck with a possibly large number of unneeded other packages. So in this case some extra feedback to the user could be helpful.

karol · 2011-04-30 22:54:21

I finally managed to file a feature request https://bugs.archlinux.org/task/24005

Inxsible · 2011-05-02 14:31:28

Thank you. I agree that it makes sense to atleast warn the user for starters.

Leonid.I · 2011-05-02 17:06:31

Inxsible wrote:

Thank you. I agree that it makes sense to atleast warn the user for starters.

What's the point, if it is already known? Besides, who said that I do not need some of the mplayer deps?

karol · 2011-05-02 17:19:27

Leonid.I wrote:

What's the point, if it is already known? Besides, who said that I do not need some of the mplayer deps?

Huh?

I want to remove mplayer and all the unneeded deps and install mplayer2 and its deps. I would like to do it in one go.

Leonid.I · 2011-05-02 18:51:50

Right, by what if you are actually using those 'unneeded deps' for purposes other than mplayer/mplayer2? Just because a package is marked "asdep" does not imply that it has no stand-alone role...

karol · 2011-05-02 19:08:57

Leonid.I wrote:

Right, by what if you are actually using those 'unneeded deps' for purposes other than mplayer/mplayer2? Just because a package is marked "asdep" does not imply that it has no stand-alone role...

I understand it's possible and I don't want to make 'pacman -Rns' the default behavior. This way you can chose the style that suits you (if it gets implemented ;P).
You can change the install reason of the standalone packages.

Inxsible · 2011-05-02 19:12:09

'unneeded deps' would mean that they are no longer needed by any app on your machine.

karol · 2011-05-02 19:18:11

Inxsible wrote:

'unneeded deps' would mean that they are no longer needed by any app on your machine.

At least in theory you can have package A that is a dependency for package B and you decide to remove package B but keep package A. Even if it was installed as a dependency for package B, you can change the install reason to 'explicitly installed'.

There shouldn't be any packages with 'Install Reason : Installed as a dependency for another package' and 'Required By : None'.

Leonid.I · 2011-05-02 20:27:05

Well, in theory. But in practice, that's going to be a mess. Example: libunique on one machine was installed asdep and correctly picked up by pacman -Qdt, while on the other it is listed as explicit. Why? who knows...

I think that the install reason should be there only for informational purposes, not as an indicator to take actions. Otherwise, to avoid wrong packages to be removed, I'll have to go through the list of packages everyday with pacman -D, as the output of pacman -Qdt changes pretty often. This kind of bookkeeping will work on a RHEL-type system, but not on a rolling release OS, especially as actively updated as Arch.

karol · 2011-05-02 20:38:20

Leonid.I wrote:

Well, in theory. But in practice, that's going to be a mess. Example: libunique on one machine was installed asdep and correctly picked up by pacman -Qdt, while on the other it is listed as explicit. Why? who knows...

There were some issues with clyde, maybe this will shed some light on the matter: https://bbs.archlinux.org/viewtopic.php … 61#p912361

Leonid.I · 2011-05-02 21:20:11

OK, let me rephrase my previous post, and compare complexities of the two situations:
(1) Current situation -- "pacman -S <-- y" replaces only the current pkg.
I have to check pacman -Qdt to remove possible leftover deps.
(2) New situation -- "pacman -S --autoclean-deps" removes the current pkg + all its unneeded deps.
I have to check pacman -Qi <current pkg> before the operation, in order to verify that nothing useful gets removed.

Personally, I think that (1) is less breakage-prone...

karol · 2011-05-02 21:55:23

Leonid.I wrote:

Personally, I think that (1) is less breakage-prone...

I agree, but nobody will take it away from you. I wanted to suggest an option to remove the unneeded dependencies more aggressively.

Seems that there is an old bug that deals with the same / similar issue https://bugs.archlinux.org/task/5974

Leonid.I · 2011-05-02 22:20:13

karol wrote:

Leonid.I wrote:
Personally, I think that (1) is less breakage-prone...
I wanted to suggest an option to remove the unneeded dependencies more aggressively.

I'm ok with that, as long as it's not the default...

karol wrote:

Seems that there is an old bug that deals with the same / similar issue https://bugs.archlinux.org/task/5974

Good point. This and your feature request do indeed ask for the same option switch. In the older report, however, the concensus seems to be in favor of the manual orphan management

EDIT: Off-topic. Does anyone know how fluxbb manages timestamps? Because right now they seem to be in a random timezone... and very inconvenient for discussions like the present one.

Last edited by Leonid.I (2011-05-02 22:22:57)

karol · 2011-05-02 22:26:55

Leonid.I wrote:

Good point. This and your feature request do indeed ask for the same option switch. In the older report, however, the concensus seems to be in favor of the manual orphan management

So maybe we can close two bugs as a 'won't fix' :-)

Leonid.I wrote:

EDIT: Off-topic. Does anyone know how fluxbb manages timestamps? Because right now they seem to be in a random timezone... and very inconvenient for discussions like the present one.

Go to your profile and fiddle with the timezones. I'm UTC +1 w/ DST and the forum timestamps are OK.

Stebalien · 2011-05-03 02:32:30

ngoonee wrote:

*Not* removing something that the user has not specified he wants removed.
Each command to pacman 'means' something. This is for the same reason that pacman -R foo doesn't remove foo's dependencies, because -R just means "please remove this package". -Rns means "please remove this package and its unused dependencies.
In the case of pacman -S bar, where bar replaces foo (but changes dependencies), there's ambiguity as to whether the user intends pacman -R or pacman -Rns, so pacman errs on the safe side.
Or, seen differently, if you want the dependency removed you're gonna have to specify that. -S does not. Perhaps you COULD request additional options to -S which would do what you want (doubt it'd have much uptake though).

Technically, the user never specified that he or she wanted the dependencies in the first place; a package that the user wanted pulled in the dependencies.

This doesn't mean that dependencies should be removed automatically, but, as Inxsible noted, users should definitely be warned when a package is orphaned (and possibly asked if it should be removed).

Arch Linux

#1 2011-04-07 17:00:32

Removing conflicting packages

#2 2011-04-07 17:28:20

Re: Removing conflicting packages

#3 2011-04-07 18:25:11

Re: Removing conflicting packages

#4 2011-04-07 19:29:52

Re: Removing conflicting packages

#5 2011-04-07 23:20:37

Re: Removing conflicting packages

#6 2011-04-08 10:44:07

Re: Removing conflicting packages

#7 2011-04-08 10:48:52

Re: Removing conflicting packages

#8 2011-04-08 11:11:00

Re: Removing conflicting packages

#9 2011-04-30 22:54:21

Re: Removing conflicting packages

#10 2011-05-02 14:31:28

Re: Removing conflicting packages

#11 2011-05-02 17:06:31

Re: Removing conflicting packages

#12 2011-05-02 17:19:27

Re: Removing conflicting packages

#13 2011-05-02 18:51:50

Re: Removing conflicting packages

#14 2011-05-02 19:08:57

Re: Removing conflicting packages

#15 2011-05-02 19:12:09

Re: Removing conflicting packages

#16 2011-05-02 19:18:11

Re: Removing conflicting packages

#17 2011-05-02 20:27:05

Re: Removing conflicting packages

#18 2011-05-02 20:38:20

Re: Removing conflicting packages

#19 2011-05-02 21:20:11

Re: Removing conflicting packages

#20 2011-05-02 21:55:23

Re: Removing conflicting packages

#21 2011-05-02 22:20:13

Re: Removing conflicting packages

#22 2011-05-02 22:26:55

Re: Removing conflicting packages

#23 2011-05-03 02:32:30

Re: Removing conflicting packages

Board footer