[pacman-dev] [PATCH] No error in makepkg when removing deps fails
From 9beeed7c54d94a95c9e0bccb863e9b09ea18bd4f Mon Sep 17 00:00:00 2001 From: Allan McRae <mcrae_allan@hotmail.com> Date: Thu, 3 Apr 2008 01:07:25 +1000 Subject: [PATCH] No error in makepkg when removing deps fails Catches error from when pacman is unable to remove dependencies after successfully building package and prints warning. Fixes FS#10039. Signed-off-by: Allan McRae <mcrae_allan@hotmail.com> --- scripts/makepkg.sh.in | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 1eb3d3a..395d525 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -447,10 +447,17 @@ remove_deps() { done msg "Removing installed dependencies..." + local ret=0 if [ "$ASROOT" = "0" ]; then - sudo pacman $PACMAN_OPTS -Rns $deplist + sudo pacman $PACMAN_OPTS -Rns $deplist || ret=$? else - pacman $PACMAN_OPTS -Rns $deplist + pacman $PACMAN_OPTS -Rns $deplist || ret=$? + fi + + # Fixes FS#10039 - exit cleanly as package has built successfully + if [ $ret -ne 0 ]; then + warning "$(gettext "Failed to remove installed dependencies.")" + return 0 fi } -- 1.5.4.5
On Wed, Apr 2, 2008 at 10:14 AM, Allan McRae <mcrae_allan@hotmail.com> wrote:
From 9beeed7c54d94a95c9e0bccb863e9b09ea18bd4f Mon Sep 17 00:00:00 2001 From: Allan McRae <mcrae_allan@hotmail.com> Date: Thu, 3 Apr 2008 01:07:25 +1000 Subject: [PATCH] No error in makepkg when removing deps fails
Catches error from when pacman is unable to remove dependencies after successfully building package and prints warning. Fixes FS#10039.
Signed-off-by: Allan McRae <mcrae_allan@hotmail.com> --- scripts/makepkg.sh.in | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 1eb3d3a..395d525 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -447,10 +447,17 @@ remove_deps() { done
msg "Removing installed dependencies..." + local ret=0 if [ "$ASROOT" = "0" ]; then - sudo pacman $PACMAN_OPTS -Rns $deplist + sudo pacman $PACMAN_OPTS -Rns $deplist || ret=$? else - pacman $PACMAN_OPTS -Rns $deplist + pacman $PACMAN_OPTS -Rns $deplist || ret=$? + fi + + # Fixes FS#10039 - exit cleanly as package has built successfully + if [ $ret -ne 0 ]; then + warning "$(gettext "Failed to remove installed dependencies.")"
Maybe print what deps we failed to remove? Or is it obvious from the pacman output? I think it would be helpful though so the user could begin undertaking manual cleanup.
+ return 0 fi }
Dan McGee wrote:
On Wed, Apr 2, 2008 at 10:14 AM, Allan McRae <mcrae_allan@hotmail.com> wrote:
+ + # Fixes FS#10039 - exit cleanly as package has built successfully + if [ $ret -ne 0 ]; then + warning "$(gettext "Failed to remove installed dependencies.")"
Maybe print what deps we failed to remove? Or is it obvious from the pacman output? I think it would be helpful though so the user could begin undertaking manual cleanup.
The pacman output would only give which package caused the failure. The packages are all installed with the --asdeps options so using "pacman -Qtd" from the chroot should make cleanup easy. However, it is easy to add it to the output if you think it would be useful. Allan
From 9beeed7c54d94a95c9e0bccb863e9b09ea18bd4f Mon Sep 17 00:00:00 2001 From: Allan McRae <mcrae_allan@hotmail.com> Date: Thu, 3 Apr 2008 01:07:25 +1000 Subject: [PATCH] No error in makepkg when removing deps fails
Catches error from when pacman is unable to remove dependencies after successfully building package and prints warning. Fixes FS#10039.
Signed-off-by: Allan McRae <mcrae_allan@hotmail.com> --- scripts/makepkg.sh.in | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 1eb3d3a..395d525 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -447,10 +447,17 @@ remove_deps() { done
msg "Removing installed dependencies..." + local ret=0 if [ "$ASROOT" = "0" ]; then - sudo pacman $PACMAN_OPTS -Rns $deplist + sudo pacman $PACMAN_OPTS -Rns $deplist || ret=$? else - pacman $PACMAN_OPTS -Rns $deplist + pacman $PACMAN_OPTS -Rns $deplist || ret=$? + fi + + # Fixes FS#10039 - exit cleanly as package has built successfully + if [ $ret -ne 0 ]; then + warning "$(gettext "Failed to remove installed dependencies.")" + return 0 fi }
-- 1.5.4.5
Well, imho this whole method is ugly. We should somehow collect the installed packages, because '-R provision' doesn't work. And trying to install dependencies with stripped pkgver, I don't know... [Not talking about the rare case of unwanted orphan removal by remove_deps] Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Wed, Apr 02, 2008 at 07:49:38PM +0200, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Well, imho this whole method is ugly. We should somehow collect the installed packages, because '-R provision' doesn't work.
what would be a solution is to store the list of installed pkgs before installing any dep then you know what you should remove. at least that's what we do in our chroot builds.
Miklos Vajna wrote:
On Wed, Apr 02, 2008 at 07:49:38PM +0200, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Well, imho this whole method is ugly. We should somehow collect the installed packages, because '-R provision' doesn't work.
what would be a solution is to store the list of installed pkgs before installing any dep then you know what you should remove. at least that's what we do in our chroot builds.
I'm looking into how to best do this at the moment. Is "pacman -Qtd" not enough here given everything is installed using --asdep? Ideally, pacman would remove the installed dependencies and this check can be removed. As Nagy said, the "-R provision" does not work at all. But this does not seem to be the case in the bug report [1]. From the bug report when building xine-lib using makechrootpkg: error: failed to prepare transaction (could not satisfy dependencies) :: openexr: requires mesa It looks like makepkg/pacman is trying to remove mesa (a makedepend) before imagemagick (another makedepend that requires openexr). So this particular case could be fixed by removing mesa from the makedepeds. I'm looking into whether this is a makepkg's fault or pacman's. I'm guessing makepkg... Allan [1] http://bugs.archlinux.org/task/10039
Allan McRae wrote:
I'm looking into how to best do this at the moment. Is "pacman -Qtd" not enough here given everything is installed using --asdep? Ideally, pacman would remove the installed dependencies and this check can be removed.
Having actually played around with this some more I see that using pacman is useless without setting up all the unionfs stuff. However, what is wrong with removing the $CHROOT_SHELL/rw directory when something like this happens? Apart from having to fix $CHROOT_SHELL/rw/etc/sudoers (makechrootpkg appears to stuff up adding the nobody user), I don't see any problem here. I could be missing something.... How else do people clean up the chroot?
It looks like makepkg/pacman is trying to remove mesa (a makedepend) before imagemagick (another makedepend that requires openexr). So this particular case could be fixed by removing mesa from the makedepeds. I'm looking into whether this is a makepkg's fault or pacman's. I'm guessing makepkg...
Turns out it is a pacman bug. If I have three packages (a, b and c) where b depends on a and c depends on b, then a "pacman -Rs a c" fails. I am making a pactest up for this now. Allan
On Thu, Apr 03, 2008 at 01:13:42PM +1000, Allan McRae <mcrae_allan@hotmail.com> wrote:
I'm looking into how to best do this at the moment. Is "pacman -Qtd" not enough here given everything is installed using --asdep? Ideally, pacman would remove the installed dependencies and this check can be removed.
As Nagy said, the "-R provision" does not work at all.
just do a -Q, save it, do a -Q after the build, diff the two list and remove the difference. so that if you did -S mta, you'll get postfix in the diff, or so.
Miklos Vajna wrote:
just do a -Q, save it, do a -Q after the build, diff the two list and remove the difference. so that if you did -S mta, you'll get postfix in the diff, or so.
I just implemented this strategy and while it would work for packages that did not bring in too many dependencies, trying to build a more complex package in a clean chroot failed due to the large number of deps installed (e.g. xine-lib brings in 88 packages). The resulting package list is too long to be removed in one command (sudo: unable to execute /usr/bin/pacman: Argument list too long). I don't see why this is necessary. If building using makepkg and you see it fails to remove deps, then get the list from "pacman -Qtd". If using makechrootpkg then just remove the "$CHROOT_SHELL/rw" directory and all is fixed. I see the failure to remove the installed packages as a failure in pacman. It should be able to "-Rs" chained dependencies and provides. I don't like working around the true source of the problem. So I doubt I will add to my initial patch - it solved the problem I was trying to solve and let the user know there was a problem removing deps which is all I think is necessary. If someone else wants to add to it then go for it. Cheers, Allan
Miklos Vajna wrote:
just do a -Q, save it, do a -Q after the build, diff the two list and remove the difference. so that if you did -S mta, you'll get postfix in the diff, or so.
I just implemented this strategy and while it would work for packages that did not bring in too many dependencies, trying to build a more complex package in a clean chroot failed due to the large number of deps installed (e.g. xine-lib brings in 88 packages). The resulting package list is too long to be removed in one command (sudo: unable to execute /usr/bin/pacman: Argument list too long).
I don't see why this is necessary. If building using makepkg and you see it fails to remove deps, then get the list from "pacman -Qtd". If using makechrootpkg then just remove the "$CHROOT_SHELL/rw" directory and all is fixed. I see the failure to remove the installed packages as a failure in pacman. It should be able to "-Rs" chained dependencies and provides. I don't like working around the true source of the problem. So I doubt I will add to my initial patch - it solved the problem I was trying to solve and let the user know there was a problem removing deps which is all I think is necessary. If someone else wants to add to it then go for it.
Cheers, Allan
In fact we cannot restore the "before build state" in some cases. To satisfy a needed dependency makepkg may _upgraded_ a package (foo>=2.0 dependency) instead of add, then why should we remove foo? vmiklos's proposal is better here, because we may get some upgraded package after build which shouldn't hurt anything. However that solution can also fail, because your upgraded foo can pull _new_ dependencies which cannot be removed then. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Fri, Apr 04, 2008 at 02:55:33PM +1000, Allan McRae <mcrae_allan@hotmail.com> wrote:
I just implemented this strategy and while it would work for packages that did not bring in too many dependencies, trying to build a more complex package in a clean chroot failed due to the large number of deps installed (e.g. xine-lib brings in 88 packages). The resulting package list is too long to be removed in one command (sudo: unable to execute /usr/bin/pacman: Argument list too long).
hmm, you do something wrong i think. chroot $CHROOTDIR pacman-g2 -Rcn $removelist --noconfirm is what i use and there is no such bug even for OOo, which has 239 dependencies (including deps' deps recursively) in Frugalware. though yes, we use sudo with makepkg itself so there is no sudo pacman here, directly.
Miklos Vajna wrote:
On Fri, Apr 04, 2008 at 02:55:33PM +1000, Allan McRae <mcrae_allan@hotmail.com> wrote:
I just implemented this strategy and while it would work for packages that did not bring in too many dependencies, trying to build a more complex package in a clean chroot failed due to the large number of deps installed (e.g. xine-lib brings in 88 packages). The resulting package list is too long to be removed in one command (sudo: unable to execute /usr/bin/pacman: Argument list too long).
hmm, you do something wrong i think.
chroot $CHROOTDIR pacman-g2 -Rcn $removelist --noconfirm
is what i use and there is no such bug even for OOo, which has 239 dependencies (including deps' deps recursively) in Frugalware.
though yes, we use sudo with makepkg itself so there is no sudo pacman here, directly.
I echo'ed the package list while I was testing and it looked fine. Maybe it is a sudo issue but it _should_ handle many more arguments than that.
participants (4)
-
Allan McRae
-
Dan McGee
-
Miklos Vajna
-
Nagy Gabor