From: ahesford <ahesford@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Updated] common/hooks/post-install/04-create-xbps-metadata-scripts.sh: fix return code of failed trigger runs
Date: Tue, 31 Aug 2021 17:39:09 +0200 [thread overview]
Message-ID: <20210831153909.xc-RdjPTqBhAfsndQpW-cP2aJozzf2d58nwMFRB3yFY@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-32120@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
There is an updated pull request by ahesford against master on the void-packages repository
https://github.com/ahesford/void-packages trigger-fix
https://github.com/void-linux/void-packages/pull/32120
common/hooks/post-install/04-create-xbps-metadata-scripts.sh: fix return code of failed trigger runs
When a template defines `$triggers`, `xbps-src` writes an `INSTALL` script that will invoke the triggers. If the triggers fail, the test in
[ $? -ne 0 ] && exit $?
will succeed and `exit` will be invoked. However, at the time `exit` is invoked, `$?` will take the value of *the test* `[ $? -ne 0 ]`, which is always `0` (or else the `&&` will short-circuit and the `exit` will not run).
The right thing to do is capture `$?` in a persistent variable, `$ret`, that can be tested and returned to properly forward the failure code through the trigger.
**NOTE**: This needs a bit of testing, because I don't yet understand the ramifications for `xbps-install` receiving a non-zero trigger return when all of them have returned `0` thus far.
A patch file from https://github.com/void-linux/void-packages/pull/32120.patch is attached
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-trigger-fix-32120.patch --]
[-- Type: text/x-diff, Size: 2829 bytes --]
From fa7d0531bcfc7da3d6fbe7d1c801791530eac5c4 Mon Sep 17 00:00:00 2001
From: "Andrew J. Hesford" <ajh@sideband.org>
Date: Wed, 21 Jul 2021 22:57:10 -0400
Subject: [PATCH] common/hooks/post-install/04-create-xbps-metadata-scripts.sh:
fix return code of failed trigger runs
This fixes an incorrect propagation of failed trigger return codes in
INSTALL scripts. The prior behavior would cause XBPS to ignore any
configuration errors and mark packages configured. Now, XBPS will report
a failure and leave all packages in the transaction unconfigured.
Return codes from triggers in REMOVE scripts are simply ignored. If a
trigger fails to run in REMOVE and XBPS notices, the package will not be
removal until (or if) the REMOVE script can be made to run error free.
This could produce an unrecoverable situation, so it seems better just
to ignore failures and proceed with removal (as happened before anyway).
---
.../04-create-xbps-metadata-scripts.sh | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/common/hooks/post-install/04-create-xbps-metadata-scripts.sh b/common/hooks/post-install/04-create-xbps-metadata-scripts.sh
index 8bb86c4487a5..4b4cd0efdb4c 100644
--- a/common/hooks/post-install/04-create-xbps-metadata-scripts.sh
+++ b/common/hooks/post-install/04-create-xbps-metadata-scripts.sh
@@ -15,11 +15,13 @@ process_metadata_scripts() {
local tmpf=$(mktemp) || exit 1
local fpattern="s|${PKGDESTDIR}||g;s|^\./$||g;/^$/d"
local targets= f= _f= info_files= home= shell= descr= groups=
- local found= triggers_found= _icondirs= _schemas= _mods= _tmpfiles=
+ local found= triggers_found= _icondirs= _schemas= _mods= _tmpfiles= trigguard=
+ # Trigger failures propagate on INSTALL but are ignored on REMOVE
+ # If REMOVE failures were propagated, packages would be uninstallable
case "$action" in
- install) ;;
- remove) ;;
+ install) trigguard="exit" ;;
+ remove) trigguard="true" ;;
*) return 1;;
esac
@@ -326,8 +328,7 @@ _EOF
if ! [[ $j =~ pre-${action} ]]; then
continue
fi
- printf "\t\${TRIGGERSDIR}/$f run $j \${PKGNAME} \${VERSION} \${UPDATE} \${CONF_FILE}\n" >> $tmpf
- printf "\t[ \$? -ne 0 ] && exit \$?\n" >> $tmpf
+ printf "\t\${TRIGGERSDIR}/$f run $j \"\${PKGNAME}\" \"\${VERSION}\" \"\${UPDATE}\" \"\${CONF_FILE}\" || ${trigguard}\n" >> $tmpf
done
done
printf "\t;;\n" >> $tmpf
@@ -338,8 +339,7 @@ _EOF
if ! [[ $j =~ post-${action} ]]; then
continue
fi
- printf "\t\${TRIGGERSDIR}/$f run $j \${PKGNAME} \${VERSION} \${UPDATE} \${CONF_FILE}\n" >> $tmpf
- printf "\t[ \$? -ne 0 ] && exit \$?\n" >> $tmpf
+ printf "\t\${TRIGGERSDIR}/$f run $j \"\${PKGNAME}\" \"\${VERSION}\" \"\${UPDATE}\" \"\${CONF_FILE}\" || ${trigguard}\n" >> $tmpf
done
done
printf "\t;;\n" >> $tmpf
next prev parent reply other threads:[~2021-08-31 15:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-22 3:03 [PR PATCH] " ahesford
2021-07-22 3:26 ` [PR PATCH] [Updated] " ahesford
2021-07-22 3:30 ` ahesford
2021-08-31 15:39 ` ahesford [this message]
2021-08-31 15:39 ` ahesford
2021-08-31 15:41 ` ahesford
2022-05-30 2:15 ` github-actions
2022-10-10 10:23 ` Duncaen
2022-10-11 17:48 ` [PR PATCH] [Closed]: " ahesford
2022-10-11 17:53 ` ahesford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210831153909.xc-RdjPTqBhAfsndQpW-cP2aJozzf2d58nwMFRB3yFY@z \
--to=ahesford@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).