[pacman-dev] [PATCH] Set an environment variable to indicate hooks support

newer
[pacman-dev] [PATCH] libmakepkg:...

older
[pacman-dev] [PATCH] Update NEWS...

Thomas Bächler

21 Feb 2016 21 Feb '16

2:40 p.m.

When replacing existing post_install and post_upgrade functionality with hooks, it is necessary to ensure that pacman has already been upgraded. To allow a smooth transition, export the ALPM_FEATURE_HOOKS variable with the value 1 in all processes spawned by pacman. An install scriptlet can fall back to old behaviour if this variable is not set, but rely on pacman hooks if it is not set. --- lib/libalpm/util.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c index 001c042..86e3943 100644 --- a/lib/libalpm/util.c +++ b/lib/libalpm/util.c @@ -545,6 +545,11 @@ static int _alpm_chroot_read_from_child(alpm_handle_t *handle, int fd, return 0; } +void _alpm_setup_child_environment() +{ + setenv("ALPM_FEATURE_HOOKS", "1", 1); +} + /** Execute a command with arguments in a chroot. * @param handle the context handle * @param cmd command to execute @@ -618,6 +623,8 @@ int _alpm_run_chroot(alpm_handle_t *handle, const char *cmd, char *const argv[], close(cwdfd); } + /* set up the child environment */ + _alpm_setup_child_environment(); /* use fprintf instead of _alpm_log to send output through the parent */ if(chroot(handle->root) != 0) { fprintf(stderr, _("could not change the root directory (%s)\n"), strerror(errno)); -- 2.7.1

Show replies by date

Thomas Bächler

21 Feb 21 Feb

2:42 p.m.

New subject: [pacman-dev] [PATCH] Set an environment variable to indicate hooks support

Am 21.02.2016 um 15:40 schrieb Thomas Bächler:

...

When replacing existing post_install and post_upgrade functionality with hooks, it is necessary to ensure that pacman has already been upgraded. To allow a smooth transition, export the ALPM_FEATURE_HOOKS variable with the value 1 in all processes spawned by pacman.

An install scriptlet can fall back to old behaviour if this variable is not set, but rely on pacman hooks if it is not set.

Typo: ^but rely on pacman hooks if it is set.

...

--- lib/libalpm/util.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c index 001c042..86e3943 100644 --- a/lib/libalpm/util.c +++ b/lib/libalpm/util.c @@ -545,6 +545,11 @@ static int _alpm_chroot_read_from_child(alpm_handle_t *handle, int fd, return 0; }

+void _alpm_setup_child_environment() +{ + setenv("ALPM_FEATURE_HOOKS", "1", 1); +} + /** Execute a command with arguments in a chroot. * @param handle the context handle * @param cmd command to execute @@ -618,6 +623,8 @@ int _alpm_run_chroot(alpm_handle_t *handle, const char *cmd, char *const argv[], close(cwdfd); }

+ /* set up the child environment */ + _alpm_setup_child_environment(); /* use fprintf instead of _alpm_log to send output through the parent */ if(chroot(handle->root) != 0) { fprintf(stderr, _("could not change the root directory (%s)\n"), strerror(errno));

Allan McRae

22 Feb 22 Feb

3:44 a.m.

New subject: [pacman-dev] [PATCH] Set an environment variable to indicate hooks support

On 22/02/16 00:40, Thomas Bächler wrote:

...

When replacing existing post_install and post_upgrade functionality with hooks, it is necessary to ensure that pacman has already been upgraded. To allow a smooth transition, export the ALPM_FEATURE_HOOKS variable with the value 1 in all processes spawned by pacman.

An install scriptlet can fall back to old behaviour if this variable is not set, but rely on pacman hooks if it is not set.

This just makes install scriptlets more complicated... The alternative approach is for stupid distribution packagers to not start using hooks while (1) there is a major bug in them and (2) it has not been announced by the distribution that everyone should update to pacman-5.0 because we now require its features.

...

--- lib/libalpm/util.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c index 001c042..86e3943 100644 --- a/lib/libalpm/util.c +++ b/lib/libalpm/util.c @@ -545,6 +545,11 @@ static int _alpm_chroot_read_from_child(alpm_handle_t *handle, int fd, return 0; }

+void _alpm_setup_child_environment() +{ + setenv("ALPM_FEATURE_HOOKS", "1", 1); +} + /** Execute a command with arguments in a chroot. * @param handle the context handle * @param cmd command to execute @@ -618,6 +623,8 @@ int _alpm_run_chroot(alpm_handle_t *handle, const char *cmd, char *const argv[], close(cwdfd); }

+ /* set up the child environment */ + _alpm_setup_child_environment();

A whole function for one line...

...

/* use fprintf instead of _alpm_log to send output through the

parent */

...

if(chroot(handle->root) != 0) { fprintf(stderr, _("could not change the root directory (%s)\n"),

strerror(errno));

...

Thomas Bächler

23 Feb 23 Feb

6:37 p.m.

New subject: [pacman-dev] [PATCH] Set an environment variable to indicate hooks support

Am 22.02.2016 um 04:44 schrieb Allan McRae:

...

On 22/02/16 00:40, Thomas Bächler wrote:

...
When replacing existing post_install and post_upgrade functionality with hooks, it is necessary to ensure that pacman has already been upgraded. To allow a smooth transition, export the ALPM_FEATURE_HOOKS variable with the value 1 in all processes spawned by pacman.

An install scriptlet can fall back to old behaviour if this variable is not set, but rely on pacman hooks if it is not set.

This just makes install scriptlets more complicated... The alternative approach is for stupid distribution packagers to not start using hooks while (1) there is a major bug in them and (2) it has not been announced by the distribution that everyone should update to pacman-5.0 because we now require its features.

So, here is the problem: We need to ensure that everyone updated to pacman 5.x before we can push an update that relies on hooks. When is that? We don't know. Do we wait a week, a month, a year? Or 76.349 days? $INSERT_ARBITRARY_NUMBER_HERE? If you upgrade your system with pacman<5, you will run a pacman version without hooks during an upgrade that may already require hooks. This will result in breakage. Especially with a package like Linux, where serious bugs occur with the current post_install process, we want to switch to hooks as fast as possible - but doing so will cause more severe bugs unless everybody has upgraded. This problem cannot be solved unless the install scriptlet is smart enough. As for the install scriptlet being "more complicated" - I think everyone can live with the line [[ -z $ALPM_FEATURE_HOOKS || $ALPM_FEATURE_HOOKS -lt 1 ]] && return at the beginning of post_upgrade (yes, very complicated, I know).

...

...
--- lib/libalpm/util.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c index 001c042..86e3943 100644 --- a/lib/libalpm/util.c +++ b/lib/libalpm/util.c @@ -545,6 +545,11 @@ static int _alpm_chroot_read_from_child(alpm_handle_t *handle, int fd, return 0; }

+void _alpm_setup_child_environment() +{ + setenv("ALPM_FEATURE_HOOKS", "1", 1); +} + /** Execute a command with arguments in a chroot. * @param handle the context handle * @param cmd command to execute @@ -618,6 +623,8 @@ int _alpm_run_chroot(alpm_handle_t *handle, const char *cmd, char *const argv[], close(cwdfd); }

+ /* set up the child environment */ + _alpm_setup_child_environment();

A whole function for one line...

I am preparing for the future. As an alternative, we can include the setenv directly in _alpm_run_chroot and only have a one line change - one that is hardly worth this discussion.

Gesh

7:20 p.m.

New subject: [pacman-dev] [PATCH] Set an environment variable to indicate hooks support

I am confused. Given that h hooks support is only provided by pacman >=5, shouldn't such PKGBUILDs require that in their depends array? Just my two cents, Gesh

Lukas Jirkovsky

7:42 p.m.

New subject: [pacman-dev] [PATCH] Set an environment variable to indicate hooks support

On 23 February 2016 at 20:20, Gesh wrote:

...

I am confused. Given that h hooks support is only provided by pacman >=5, shouldn't such PKGBUILDs require that in their depends array?

Just my two cents, Gesh

While that would ensure the pacman is upgraded to 5.0, there's no guarantee it would be upgraded before the package requiring hooks.

Lukas Fleischer

24 Feb 24 Feb

8:54 a.m.

New subject: [pacman-dev] [PATCH] Set an environment variable to indicate hooks support

On Tue, 23 Feb 2016 at 20:42:36, Lukas Jirkovsky wrote:

...

On 23 February 2016 at 20:20, Gesh wrote:

...
I am confused. Given that h hooks support is only provided by pacman >=5, shouldn't such PKGBUILDs require that in their depends array?

Just my two cents, Gesh

While that would ensure the pacman is upgraded to 5.0, there's no guarantee it would be upgraded before the package requiring hooks.

Talking about Arch Linux: Could we simply add a news entry and tell people to upgrade pacman and its dependencies first, as we usually do when this kind of situation arises? Of course, we would need to make sure that none of the dependencies use hooks for the time being...

2986

Age (days ago)

2989

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Allan McRae
Gesh
Lukas Fleischer
Lukas Jirkovsky
Thomas Bächler