Github messages for voidlinux
 help / color / mirror / Atom feed
From: ahesford <>
Subject: Re: common/hooks/post-install/ fix return code of failed trigger runs
Date: Tue, 31 Aug 2021 17:39:19 +0200	[thread overview]
Message-ID: <20210831153919.UtXNRe007miZsmaQvXJ0_IQeL1ArPzqztsWHmqzElVQ@z> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

New comment by ahesford on void-packages repository

OK, I had some time to test this some more. I modied the `pycompile` trigger to always `exit 1` in place of the current `exit 0`, then tried installing an existing `python3-setuptools` package. (The existing package has the old `INSTALL` behavior that this PR fixes.)

With the existing behavior, the `INSTALL` script consumes all trigger failures. Failures in the triggers may or may not cause some information to be printed to stdout (this obviously depends on the trigger scripts), but XBPS never sees a nonzero return code. It happily reports a successful installation:
python3-setuptools-57.0.0_1: configuring ...
Byte-compiling python3.9 code for module _distutils_hack...
Byte-compiling python3.9 code for module pkg_resources...
Byte-compiling python3.9 code for module setuptools...
Updating ldconfig(8) cache...
python3-setuptools-57.0.0_1: installed successfully.

7 downloaded, 7 installed, 0 updated, 7 configured, 0 removed.
The `xbps-install` process returns `0` and the package `python3-setuptools` shows up as installed and configured (`ii`) in the output of `xbps-query -l`.

After rebuilding the `python3-setuptools` package to get an `INSTALL` script with fixed behavior, `xbps-install` instead reports
python3-setuptools-57.0.0_2: configuring ...
Byte-compiling python3.9 code for module pkg_resources...
Byte-compiling python3.9 code for module setuptools...
Byte-compiling python3.9 code for module _distutils_hack...
Updating ldconfig(8) cache...
ERROR: python3-setuptools-57.0.0_2: [configure] INSTALL script failed to execute the post ACTION: Operation not permitted
Transaction failed! see above for errors.
and returns `1`. While the package is installed, it remains in an unconfigured state (`uu` in the output of `xbps-query -l`). In fact, every package installed as part of the transaction remains unconfigured. Attempted to reconfigure the packages causes the same error and leaves the packages unconfigured. Running `xbps-reconfigure -a` will leave all unconfigured packages in the same unconfigured state. However, those packages with triggers that do not fail can be individually configured in separate transactions.

When removing a package, any removal triggers (like `pycompile` in this test) will report failure and abort the installation, leaving the package installed and whatever configuration state it was in before the removal. (Note that some part of the removal trigger may have run, so package state may have changed even though the package remains installed.) Even `xbps-remove -f` seems to fail here, so the package will be uninstallable as long as the removal hook fails.

1. I think propagating the install errors through to XBPS is the right behavior, and leaving the packages unconfigured is also correct. The configuration failed, so the package shouldn't be marked configured. However, who knows how many triggers leak unexpected nonzero returns harmlessly? We don't know.
2. Propagating the nonzero return on *remove* seems a bit risky here. The package will be effectively uninstallable until (or if) the removal hook can be run without errors. It's probably better to just swallow the error and allow the removal to proceed. I've updated the change to impose this behavior.
3. This behavior won't take effect in packages until they are rebuilt with the new `xbps-src` hook. I don't think there's a need to bulk rebuild everything; the fix can leak in by attrition.

  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 ` [PR PATCH] [Updated] " ahesford
2021-08-31 15:39 ` ahesford [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210831153919.UtXNRe007miZsmaQvXJ0_IQeL1ArPzqztsWHmqzElVQ@z \ \ \

* 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).