[pacman-dev] [PATCH v2 1/3] configure: bump the minimum version of bash to 4.4
This is required in order to use declare -g and ${var@a}
Signed-off-by: Eli Schwartz
This re-applies commit 9e52a36794552b77ecf26f7f34b226d096978f1e with
fixes after reverting it in 10ca4f48311370cdd580f66096d5e94858fde467 for
the maintenance release.
The split package metadata backup/restore was initially refactored to
use declare, which actually declares variables in a local scope when in
a function. This did not play nicely with debug packages, which unset
most metadata variables, thereby reverting to the global scope rather
than resulting in unset metadata.
This could be fixed by explicitly marking the variables as global, or,
alternatively, by refactoring everything to use local function
variables. However, the latter simply moves the issue to other areas
(what happens if a user-defined package function uses unset instead of
foo=() for the same effect).
Now that the minimum version of bash has been raised, it is safe to once
more apply (a working version of) this enhancement.
Signed-off-by: Eli Schwartz
Now that we require bash 4.4 this is "more correct" than analyzing the
output of declare -p to see if it compares favorably with -a.
Signed-off-by: Eli Schwartz
On 20/06/18 06:26, Eli Schwartz wrote:
This re-applies commit 9e52a36794552b77ecf26f7f34b226d096978f1e with fixes after reverting it in 10ca4f48311370cdd580f66096d5e94858fde467 for the maintenance release.
The split package metadata backup/restore was initially refactored to use declare, which actually declares variables in a local scope when in a function. This did not play nicely with debug packages, which unset most metadata variables, thereby reverting to the global scope rather than resulting in unset metadata.
This could be fixed by explicitly marking the variables as global, or, alternatively, by refactoring everything to use local function variables. However, the latter simply moves the issue to other areas (what happens if a user-defined package function uses unset instead of foo=() for the same effect).
Now that the minimum version of bash has been raised, it is safe to once more apply (a working version of) this enhancement.
Signed-off-by: Eli Schwartz
--- v2: patchset now targets pacman 6.x and is rebased onto https://patchwork.archlinux.org/patch/631/
Can you provide an example PKGBUILD that demonstrated the bug? Thanks, A
On 20/06/18 06:26, Eli Schwartz wrote:
This re-applies commit 9e52a36794552b77ecf26f7f34b226d096978f1e with fixes after reverting it in 10ca4f48311370cdd580f66096d5e94858fde467 for the maintenance release.
The split package metadata backup/restore was initially refactored to use declare, which actually declares variables in a local scope when in a function. This did not play nicely with debug packages, which unset most metadata variables, thereby reverting to the global scope rather than resulting in unset metadata.
This could be fixed by explicitly marking the variables as global, or, alternatively, by refactoring everything to use local function variables. However, the latter simply moves the issue to other areas (what happens if a user-defined package function uses unset instead of foo=() for the same effect).
Now that the minimum version of bash has been raised, it is safe to once more apply (a working version of) this enhancement.
Signed-off-by: Eli Schwartz
--- v2: patchset now targets pacman 6.x and is rebased onto https://patchwork.archlinux.org/patch/631/
So, this patch is also broken. Given the number of "fixed" versions that have been posted so far, I will not accept a patch touching this piece of code again unless it fixes a genuine bug. And given that no bugs have been found in that code in the nine years since the pacman-3.2 release it was introduced in... A
On Tue, 19 Jun 2018 16:26:33 -0400, Eli Schwartz wrote:
This is required in order to use declare -g and ${var@a}
Huh? It's needed for @a, but wasn't `declare -g` in Bash 4.2? -- Happy hacking, ~ Luke Shumaker
On 07/12/2018 01:30 AM, Luke Shumaker wrote:
On Tue, 19 Jun 2018 16:26:33 -0400, Eli Schwartz wrote:
This is required in order to use declare -g and ${var@a}
Huh? It's needed for @a, but wasn't `declare -g` in Bash 4.2?
We moved from bash 4.1, it's quite genuine to say that moving from bash 4.1 to bash 4.4 enables using declare -g. -- Eli Schwartz Bug Wrangler and Trusted User
participants (3)
-
Allan McRae
-
Eli Schwartz
-
Luke Shumaker