[Solved] --noconfirm when conflicting packages

jernst · 2018-01-04 04:24:09

% pacman -S --noconfirm mod_wsgi --force
resolving dependencies...
looking for conflicting packages...
:: mod_wsgi and mod_wsgi2 are in conflict. Remove mod_wsgi2? [y/N] 
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: mod_wsgi and mod_wsgi2 are in conflict

Naively I was expecting that --noconfirm and --force would force the installation of mod_wsgi, and removal of mod_wsgi2, but it doesn't seem to. Is there a way of doing this non-interactively?

Cheers,

Johannes.

Last edited by jernst (2018-01-04 19:17:55)

Trilby · 2018-01-04 04:28:57

Just remove one, then install the other.

jernst · 2018-01-04 04:58:45

Hmm, this is part of a non-interactive script and I'd prefer a solution that isn't specific to particular packages (like mod_wsgiX here). I'm sure that happens for other package combinations, too.

It seems I would have to basically parse the output of the failing command, decide which package needs to be removed and then do that first. Alternatively I'd have to simulate an interactive command by piping in "y" or such. Or alternatively reinterpret --noconfirm to also mean "agree to remove conflicting package" with a suitable pacman patch.

eschwartz · 2018-01-04 05:31:16

Noconfirm means precisely that -- don't "confirm". Note how the options you were given asked you to answer [y/N] indicating that N was the default if you simply press enter, or use --noconfirm.

The fact that removing conflicting packages, is defined in the codebase as [y/N], is a deliberate design decision. Don't bother wasting your time asking for that to be changed.

pacman is not designed to be scriptable like that, users are really supposed to keep an eye on progress. But as you pointed out, piping `yes y|pacman -S` works fine. Alternatively, you can use pacutils, since the pacinstall command allows you to specify packages to install alongside packages to remove, in the same transaction.

Trilby · 2018-01-04 13:07:42

Why would you need to parse any output? There may be many other packages, but you are writing the script, so you clearly know what those packages are ahead of time. And if this is a large migration from everything python2 to everything python3, then you could select the proper flags to remove python2 and everything that depends on it (which would include this example) then install your list of python 3 packages.

What is the actual use case here? What are you really trying to do?

jernst · 2018-01-04 18:27:58

I don't know what the packages are ahead of time. The scripts are a bunch of code on top of pacman that helps with the installation, provisioning, configuration and management of an open-ended list of web applications. (The scripts are independent of the actual apps, so I don't know) For an example: [1] These are admittedly out of scope for what Arch attempts to do, which is why I never advocated for support in Arch directly but I do occasionally attempt to find out just where exactly the boundaries are, thus questions like this one :-) I ran into this particular problem when one of those apps moved from Python2 to Python3, and our scripts failed to update dependencies correctly.

But it's okay. I will pipe in "y" and that will hopefully get me what I need.

[1] https://ubos.net/docs/developers/unders … eploy.html

apg · 2018-01-04 18:39:12

If you don't know what the conflicts are ahead of time, why would you want to non-interactively remove the package? Blindly removing unknown packages is a great way to break things.

Trilby · 2018-01-04 18:53:43

jernst wrote:

I ran into this particular problem when one of those apps moved from Python2 to Python3

So it's the scenario I already mentioned. And it's so rare as to be considered an isolated acception.

Packages are not-irregularly replaced by others, but then they'll have conflicts and replaces fields set and pacman will process them as you'd like (you'd probably still need noconfirm, but definitely not force).

But for this case of switching to python3 it's easy, assuming the higher level package that switched from using python2 deps to python3 deps was called "leaf package":

pacman -Rs leaf-package
pacman -S leaf-package

Removing with the 's' flag will remove all those python2 dependencies of leaf-package. Then installing the new leaf-package will pull in the python3 deps. No conflicts.

The only hurdle with this is if there were several such packages. But that is trivial too: just remove them all at once (with -Rs), then install all the new ones. So even if the package names are just in a variable:

pacman -Rs $package
pacman -S $packages

If there are no such top level packages (I suspect there must be, but playing devils advocate here) make one: a meta-package that depends on what you need.

Last edited by Trilby (2018-01-04 18:55:20)

jernst · 2018-01-04 19:17:36

Trilby wrote:

But for this case of switching to python3 it's easy, assuming the higher level package that switched from using python2 deps to python3 deps was called "leaf package":
pacman -Rs leaf-package
pacman -S leaf-package
Removing with the 's' flag will remove all those python2 dependencies of leaf-package. Then installing the new leaf-package will pull in the python3 deps. No conflicts.

This might be the better plan, I appreciate it. I think I will keep what I was doing, but watch the pacman output for indication of a conflict. If it occurs, then I do what you suggest, one conflicting package at a time.

eschwartz · 2018-01-04 19:20:01

Well, "replaces" is definitely the key here. In fact, "replaces" means you can just -Syu without specifying the new package at all.

Trilby · 2018-01-04 19:23:32

Eschwartz, replaces would only help if it were added to all the python3 packages to replace their python2 counterparts. But they don't replace them. They really do just conflict.

Having leaf-pkg v3 replace leaf-pkg v2 wouldn't help: all leaf-pkg v2's dependencies (the python2 packages) need to be removed before v3 can be installed.

eschwartz · 2018-01-04 20:29:10

For dependencies like python modules it usually doesn't matter, as the python2 and python3 versions will not (or should not, if they are properly written) conflict at all.

Replaces is useful in a narrow subset of situations, those being, whenever a package that serves a specific functionality is purged from existence and replaced with a renamed package. And that is the same subset of situations that I would think applies to "my software has migrated from X to Y".

...

What I neglected to realize is that mod_wsgi and mod_wsgi2 are repository packages which install the same apache plugin, without any versioning. Which seems... less than ideal. https://github.com/GrahamDumpleton/mod_wsgi/issues/21

jernst · 2018-01-04 20:35:03

It would be nice if mod_wsgi and mod_wsgi2 did not conflict, that's true. But presumably that would require more patching of the code to have a second set of Apache config directives, like WSGIxxx and WSGI2xxx.

AlphaJack · 2022-08-26 14:44:09

https://unix.stackexchange.com/a/584001/423407 helped me to replace iptables with iptables-nft automatically

Slithery · 2022-08-26 14:55:29

Don't necrobump. Expecially with undocumented options which may be removed at any time without notice.

Closing this old thread.

Arch Linux

#1 2018-01-04 04:24:09

[Solved] --noconfirm when conflicting packages

#2 2018-01-04 04:28:57

Re: [Solved] --noconfirm when conflicting packages

#3 2018-01-04 04:58:45

Re: [Solved] --noconfirm when conflicting packages

#4 2018-01-04 05:31:16

Re: [Solved] --noconfirm when conflicting packages

#5 2018-01-04 13:07:42

Re: [Solved] --noconfirm when conflicting packages

#6 2018-01-04 18:27:58

Re: [Solved] --noconfirm when conflicting packages

#7 2018-01-04 18:39:12

Re: [Solved] --noconfirm when conflicting packages

#8 2018-01-04 18:53:43

Re: [Solved] --noconfirm when conflicting packages

#9 2018-01-04 19:17:36

Re: [Solved] --noconfirm when conflicting packages

#10 2018-01-04 19:20:01

Re: [Solved] --noconfirm when conflicting packages

#11 2018-01-04 19:23:32

Re: [Solved] --noconfirm when conflicting packages

#12 2018-01-04 20:29:10

Re: [Solved] --noconfirm when conflicting packages

#13 2018-01-04 20:35:03

Re: [Solved] --noconfirm when conflicting packages

#14 2022-08-26 14:44:09

Re: [Solved] --noconfirm when conflicting packages

#15 2022-08-26 14:55:29

Re: [Solved] --noconfirm when conflicting packages

Board footer