You are not logged in.
With the noconfirm option, pacman answers no when trying to resolve conflicts. How do I make it answer yes?[solved]
Last edited by altaway (2020-10-23 16:14:06)
Offline
Does the replacement package list the package it is replacing in both conflicts and replaces arrays?
Offline
pacman is not optimized for scripting. Install pacutils, and use pacinstall --no-confirm --resolve-conflicts=all, or perhaps pacinstall --yolo
See the manpage: https://jlk.fjfi.cvut.cz/arch/manpages/ … on_Options
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
To be more specific, I am trying to build certain packages from the AUR using makepkg. There are certain packages whose build dependencies conflict with each other. What's the best way to handle this?
Last edited by altaway (2020-06-06 06:24:08)
Offline
To be specific...
Not specific at all
Offline
pacman is not optimized for scripting. Install pacutils, and use pacinstall --no-confirm --resolve-conflicts=all, or perhaps pacinstall --yolo
See the manpage: https://jlk.fjfi.cvut.cz/arch/manpages/ … on_Options
I came to know about pacutils thanks to you, mate.
Is it possible to replace makepkg with something from pacutils?
Last edited by altaway (2020-06-06 06:46:21)
Offline
Or you can just confirm "yes" yourself. What's the actual use case here, and how do you get to the conflicts in the first place?
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
1. makepkg is part of a script.
2. The script runs in a devops environment, so the session isn't interactive.
3. The script is supposed to build package1 and package2 by taking the PKGBUILDs from the AUR. package1 has builddeps a, b, c. package2 has builddeps d, e, f.
4. "makepkg -sr --noconfirm" seems to be the thing I am looking for.
Offline
Build each package in their own clean chroot and avoid the conflicts completely.
https://wiki.archlinux.org/index.php/De … ean_chroot
Last edited by Lone_Wolf (2020-06-06 18:59:32)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Chroots can't avoid conflicts when packages conflict with say, base. (Less likely with the slimmed down base package though.)
Last edited by Alad (2020-06-06 20:44:37)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
To be more specific, I am trying to build certain packages from the AUR using makepkg. There are certain packages whose build dependencies conflict with each other. What's the best way to handle this?
See, now that would have been useful knowledge to have from the start.
Is it possible to replace makepkg with something from pacutils?
Theoretically, anything is possible. You could add a shellscript to $PATH which is named "pacman", but diverts package installations to use pacinstall. You'll have to be exceedingly careful, however, since makepkg internally uses pacman for a number of things including parsing the output of pacman -Qi or pacman -T, so you'd need a good enough option parser to imitate pacman and forward invocations to /usr/bin/pacman *except* when you know it is trying to install a package.
Have you considered implementing makedepends solving outside of makepkg? Use makepkg --printsrcinfo or bash -c 'source PKGBUILD; printf "%s\n" "${makedepends[@]}" "${makedepends_x86_64[@]}" "${depends[@]}" "${depends_x86_64[@]}"' to collect build dependencies, and install them by hand, possibly using pacutils.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Theoretically, anything is possible. You could add a shellscript to $PATH which is named "pacman", but diverts package installations to use pacinstall. You'll have to be exceedingly careful, however, since makepkg internally uses pacman for a number of things including parsing the output of pacman -Qi or pacman -T, so you'd need a good enough option parser to imitate pacman and forward invocations to /usr/bin/pacman *except* when you know it is trying to install a package.
Or use PACMAN=/bin/my_pacman, to only affect makepkg and not other programs running pacman.
Have you considered implementing makedepends solving outside of makepkg? Use makepkg --printsrcinfo or bash -c 'source PKGBUILD; printf "%s\n" "${makedepends[@]}" "${makedepends_x86_64[@]}" "${depends[@]}" "${depends_x86_64[@]}"' to collect build dependencies, and install them by hand, possibly using pacutils.
This part seems relatively straightforward. I wonder how to reimplement `-r` though, since you'd need to keep track both of what dependencies were installed, and which (possibly already installed) dependencies were replaced by pacinstall.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Have you considered implementing makedepends solving outside of makepkg? Use makepkg --printsrcinfo or bash -c 'source PKGBUILD; printf "%s\n" "${makedepends[@]}" "${makedepends_x86_64[@]}" "${depends[@]}" "${depends_x86_64[@]}"' to collect build dependencies, and install them by hand, possibly using pacutils.
This part seems relatively straightforward. I wonder how to reimplement `-r` though, since you'd need to keep track both of what dependencies were installed, and which (possibly already installed) dependencies were replaced by pacinstall.
makepkg doesn't try to track the latter. Or actually it does, and if it detects that this has happened, it fails with a warning. The comments say it is "too risky" to remove all installed packages in this case.
Otherwise it just diffs the before-list and the after-list and removes all new packages. It's pretty simple to do...
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
My question then remains, is there a way to "try to track the latter"? I mean, I wouldn't want to remove all installed packages either, but rather keep track of which conflicts were solved with pacinstall, then do those same transactions in the opposite direction during cleanup.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Well, you could try to do a two-way diff then use pactrans to install all packages which were removed and remove all packages which were installed, thus resetting the system to its initial state. This would be slightly complicated by -i, especially if you need to handle runtime-only depends which may or may not also be makedepends....
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
You know what needs to be replaced, so just have the script do it before running makepkg.
Offline