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

[Thomas Bächler]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20160223/1b83ecdd/attachment.asc>