June 2018 - Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] libalpm: ignore .hook suffix when sorting hooks
by Jouke Witteveen 03 Aug '18

03 Aug '18

It is desirable to have 'a-post.hook' ordered after 'a.hook'. For this, it is needed to ignore the suffix when sorting. --- Two years ago, I suggested this patch in https://bugs.archlinux.org/task/49653. Today, I do so again :-). Thanks to Jelle van der Waa for pointing me to the correct list. Regards, - Jouke lib/libalpm/hook.c | 16 ++++++++++++---- lib/libalpm/hook.h | 2 ++ 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/lib/libalpm/hook.c b/lib/libalpm/hook.c index 0805e661..d90ed2da 100644 --- a/lib/libalpm/hook.c +++ b/lib/libalpm/hook.c @@ -551,7 +551,16 @@ static int _alpm_hook_triggered(alpm_handle_t *handle, struct _alpm_hook_t *hook static int _alpm_hook_cmp(struct _alpm_hook_t *h1, struct _alpm_hook_t *h2) { - return strcmp(h1->name, h2->name); + size_t suflen = strlen(ALPM_HOOK_SUFFIX), l1, l2; + int ret; + l1 = strlen(h1->name) - suflen; + l2 = strlen(h2->name) - suflen; + /* exclude the suffixes from comparison */ + ret = strncmp(h1->name, h2->name, l1 <= l2 ? l1 : l2); + if(ret == 0 && l1 != l2) { + return l1 < l2 ? -1 : 1; + } + return ret; } static alpm_list_t *find_hook(alpm_list_t *haystack, const void *needle) @@ -634,8 +643,7 @@ int _alpm_hook_run(alpm_handle_t *handle, alpm_hook_when_t when) alpm_event_hook_t event = { .when = when }; alpm_event_hook_run_t hook_event; alpm_list_t *i, *hooks = NULL, *hooks_triggered = NULL; - const char *suffix = ".hook"; - size_t suflen = strlen(suffix), triggered = 0; + size_t suflen = strlen(ALPM_HOOK_SUFFIX), triggered = 0; int ret = 0; for(i = alpm_list_last(handle->hookdirs); i; i = alpm_list_previous(i)) { @@ -681,7 +689,7 @@ int _alpm_hook_run(alpm_handle_t *handle, alpm_hook_when_t when) memcpy(path + dirlen, entry->d_name, name_len + 1); if(name_len < suflen - || strcmp(entry->d_name + name_len - suflen, suffix) != 0) { + || strcmp(entry->d_name + name_len - suflen, ALPM_HOOK_SUFFIX) != 0) { _alpm_log(handle, ALPM_LOG_DEBUG, "skipping non-hook file %s\n", path); continue; } diff --git a/lib/libalpm/hook.h b/lib/libalpm/hook.h index 364d22d7..30d565df 100644 --- a/lib/libalpm/hook.h +++ b/lib/libalpm/hook.h @@ -22,6 +22,8 @@ #include "alpm.h" +#define ALPM_HOOK_SUFFIX ".hook" + int _alpm_hook_run(alpm_handle_t *handle, alpm_hook_when_t when); #endif /* ALPM_HOOK_H */ -- 2.17.1

3 6

[pacman-dev] [PATCH v2] alpm-hooks.5: include more information on hook files
by Jouke Witteveen 19 Jul '18

19 Jul '18

--- I'm sorry for sending a revision of such a minor patch, but I could not stand having messed up the line lengths. This is a follow-up to my hook sorting patch. The information added is also available in pacman.conf(5), and in pacman(8), but this looks like a good place to repeat it. Regards, - Jouke doc/alpm-hooks.5.asciidoc | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/doc/alpm-hooks.5.asciidoc b/doc/alpm-hooks.5.asciidoc index 1d19f96e..e6f1f8e3 100644 --- a/doc/alpm-hooks.5.asciidoc +++ b/doc/alpm-hooks.5.asciidoc @@ -30,9 +30,14 @@ DESCRIPTION libalpm provides the ability to specify hooks to run before or after transactions based on the packages and/or files being modified. Hooks consist of a single '[Action]' section describing the action to be run and one or more -'[Trigger]' section describing which transactions it should be run for. Hook -file names are required to have the suffix ".hook". Hooks are run in -alphabetical order of their file name. +'[Trigger]' section describing which transactions it should be run for. + +Hooks are read from files located in the system hook directory ++{datarootdir}/libalpm/hooks+, and additional custom directories. Additional +directories are specified linkman:pacman.conf[5]. The default additional +directory is +{sysconfdir}/pacman.d/hooks+. Hook file names are required to +have the suffix ".hook". Hooks are run in alphabetical order of their file +name, where the ordering ignores the suffix. TRIGGERS -------- -- 2.18.0

2 1

[pacman-dev] [PATCH] doc: declare what type of comments we support in pacman.conf
by Eli Schwartz 19 Jul '18

19 Jul '18

Ini-style configuration formats are all over the place. So are we, for that matter, as we switched how we treated middle-of-line comments in commit 8a19c4a78251c5e34ecf508a65d943ca2dc833c7 -- namely, they're not comments anymore. This is surprising to users, who report bugs because it used to work, but what's more surprising is that the only "documentation" for the type of comments users can be expected to use, is by guessing from our example pacman.conf and maybe discovering unreliable easter eggs. Fixes FS#58809 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- doc/pacman.conf.5.asciidoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/pacman.conf.5.asciidoc b/doc/pacman.conf.5.asciidoc index e5fffecf..157e00ee 100644 --- a/doc/pacman.conf.5.asciidoc +++ b/doc/pacman.conf.5.asciidoc @@ -19,6 +19,8 @@ Each section defines a package repository that pacman can use when searching for packages in '\--sync' mode. The exception to this is the options section, which defines global options. +Comments are supported, only by beginning a line with the hash (#) symbol. + Example ------- -- 2.17.1

2 2

[pacman-dev] [PATCH v2 1/3] configure: bump the minimum version of bash to 4.4
by Eli Schwartz 12 Jul '18

12 Jul '18

This is required in order to use declare -g and ${var@a} Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index fb9d18e1..6ba9d737 100644 --- a/configure.ac +++ b/configure.ac @@ -193,18 +193,18 @@ AC_DEFUN([AX_PROG_PERL_VERSION], AX_PROG_PERL_VERSION([5.10.1], [], [AC_MSG_ERROR([perl is too old])]) AS_IF([test "x$BASH_SHELL" = "xfalse"], - AC_MSG_WARN([*** bash >= 4.1.0 is required for pacman scripts]), + AC_MSG_WARN([*** bash >= 4.4.0 is required for pacman scripts]), [bash_version_major=`$BASH_SHELL -c 'echo "${BASH_VERSINFO[[0]]}"'` bash_version_minor=`$BASH_SHELL -c 'echo "${BASH_VERSINFO[[1]]}"'` ok=yes if test "$bash_version_major" -lt 4; then ok=no fi - if test "$bash_version_major" -eq 4 && test "$bash_version_minor" -lt 1; then + if test "$bash_version_major" -eq 4 && test "$bash_version_minor" -lt 4; then ok=no fi if test "$ok" = "no"; then - AC_MSG_ERROR([*** bash >= 4.1.0 is required for pacman scripts]) + AC_MSG_ERROR([*** bash >= 4.4.0 is required for pacman scripts]) fi unset bash_version_major bash_version_minor ok]) -- 2.17.1

3 6

[pacman-dev] Regarding pacman's "No database errors have been found!"-message.
by Peter Krauß 25 Jun '18

25 Jun '18

Hello! I suggest to remove pacman's "No database errors have been found!" message and instead have it replaced by an actual error message in case an error has been found. The expected behavior of pacman is that there are no database errors and thus it's less confusing for users to show the message only in cases of something unexpected happening. Any opinions on this? Cheers, Peter

2 1

[pacman-dev] [PATCH] makepkg: reject PKGBUILDs with both split and non-split package functions
by Eli Schwartz 21 Jun '18

21 Jun '18

We accept package_foo() in non-split packages, because it's easier to switch to/from a split package just by removing a pkgname element. But it makes no sense to have both in one PKGBUILD. Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/libmakepkg/lint_pkgbuild/package_function.sh.in | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/scripts/libmakepkg/lint_pkgbuild/package_function.sh.in b/scripts/libmakepkg/lint_pkgbuild/package_function.sh.in index e52f1325..457b8f67 100644 --- a/scripts/libmakepkg/lint_pkgbuild/package_function.sh.in +++ b/scripts/libmakepkg/lint_pkgbuild/package_function.sh.in @@ -34,11 +34,18 @@ lint_package_function() { local i ret=0 if (( ${#pkgname[@]} == 1 )); then - if have_function 'build' && ! { have_function 'package' || have_function "package_$pkgname"; }; then + if have_function 'package' && have_function "package_$pkgname"; then + error "$(gettext "Duplicate %s and %s functions in %s")" "package()" "package_$pkgname()" "$BUILDFILE" + ret=1 + elif have_function 'build' && ! { have_function 'package' || have_function "package_$pkgname"; }; then error "$(gettext "Missing %s function in %s")" "package()" "$BUILDFILE" ret=1 fi else + if have_function "package"; then + error "$(gettext "Extra %s function for split package '%s'")" "package()" "$pkgbase" + ret=1 + fi for i in "${pkgname[@]}"; do if ! have_function "package_$i"; then error "$(gettext "Missing %s function for split package '%s'")" "package_$i()" "$i" -- 2.17.1

2 2

[pacman-dev] pacman 5.1.1 and the "final" makepkg bug
by Allan McRae 21 Jun '18

21 Jun '18

Hi all, I think we are near the point for a pacman-5.1.1 release. My intention is for it to be basically what on master current + the couple of patches in my patchqueue branch. The final thing that needs addressing is: https://bugs.archlinux.org/task/58776 The gist of this bug is makepkg --printsrcinfo was giving entries like "depends = perl>=". We caught these entries because they could be a genuine mistake. It turns out this also happens when the version used requires some bash that calls a function or variable that is not at a global scope. While this is fairly easily worked around, it breaks all perl PKGBUILDs that use the makepkg-template in Arch Linux, and removes the "anything correct bash is OK" mantra of PKGBUILDs. I see some choices here: 1) back out the change 2) partially back out the change 3) "hide" the change 4) document the change For 2), I could see changing the error to a warning, documenting the change and including it for next release. For 3), we could print a warning, then strip these empty "<=" at the end. Note libprovides and libdepends have dynamcially generated versions that are not in --sourceinfo so this would align with them. We should document that limitation. Opinions? (I'm leaning towards #3) Allan

2 2

[pacman-dev] [PATCH] libmakepkg: remove accidentally added file
by Allan McRae 21 Jun '18

21 Jun '18

A blank file slipped into libmakepkg in commit 2c94118d. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/libmakepkg/lint_pkgbuild/3 | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 scripts/libmakepkg/lint_pkgbuild/3 diff --git a/scripts/libmakepkg/lint_pkgbuild/3 b/scripts/libmakepkg/lint_pkgbuild/3 deleted file mode 100644 index e69de29b..00000000 -- 2.17.1

1 0

[pacman-dev] [PATCH] alpm-hooks.5: include more information on hook files
by Jouke Witteveen 20 Jun '18

20 Jun '18

--- This is a follow-up to my hook sorting patch. The information added is also available in pacman.conf(5), and in pacman(8), but this looks like a good place to repeat it. doc/alpm-hooks.5.asciidoc | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/doc/alpm-hooks.5.asciidoc b/doc/alpm-hooks.5.asciidoc index 1d19f96e..cf8d2710 100644 --- a/doc/alpm-hooks.5.asciidoc +++ b/doc/alpm-hooks.5.asciidoc @@ -30,9 +30,14 @@ DESCRIPTION libalpm provides the ability to specify hooks to run before or after transactions based on the packages and/or files being modified. Hooks consist of a single '[Action]' section describing the action to be run and one or more -'[Trigger]' section describing which transactions it should be run for. Hook -file names are required to have the suffix ".hook". Hooks are run in -alphabetical order of their file name. +'[Trigger]' section describing which transactions it should be run for. + +Hooks are read from files located in the system hook directory ++{datarootdir}/libalpm/hooks+, and additional custom directories. Additional +directories are specified linkman:pacman.conf[5]. The default +additional directory is +{sysconfdir}/pacman.d/hooks+. Hook file names are +required to have the suffix ".hook". Hooks are run in alphabetical order of +their file name, where the ordering ignores the suffix. TRIGGERS -------- -- 2.17.1

1 0

[pacman-dev] [PATCH 1/6] libmakepkg/util/option: Refactor checking to reduce code duplication
by Jan Alexander Steffens (heftig) 19 Jun '18

19 Jun '18

Pull out the expected=y/n check into a separate function and make use of the fact we can just prepend the fallback arrays to get the same result. --- scripts/libmakepkg/util/option.sh.in | 85 +++++++++------------------- 1 file changed, 28 insertions(+), 57 deletions(-) diff --git a/scripts/libmakepkg/util/option.sh.in b/scripts/libmakepkg/util/option.sh.in index 46e0568d..3299df9c 100644 --- a/scripts/libmakepkg/util/option.sh.in +++ b/scripts/libmakepkg/util/option.sh.in @@ -48,95 +48,66 @@ in_opt_array() { } +## +# usage : check_opt_array( $option, $expected_val, $haystack ) +# return : 0 - matches expected +# 1 - does not match expected +# 127 - not found +## +check_opt_array() { + local option=$1 expected=$2; shift 2 + + in_opt_array "$option" "$@" + case $? in + 0) # assert enabled + [[ $expected = y ]] + return ;; + 1) # assert disabled + [[ $expected = n ]] + return ;; + esac + + # not found + return 127 +} + + ## # Checks to see if options are present in makepkg.conf or PKGBUILD; # PKGBUILD options always take precedence. # # usage : check_option( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_option() { - in_opt_array "$1" ${options[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # fall back to makepkg.conf options - in_opt_array "$1" ${OPTIONS[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # not found - return 127 + check_opt_array "$@" "${OPTIONS[@]}" "${options[@]}" } ## # Check if option is present in BUILDENV # # usage : check_buildenv( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_buildenv() { - in_opt_array "$1" ${BUILDENV[@]} - case $? in - 0) # assert enabled - [[ $2 = "y" ]] - return ;; - 1) # assert disabled - [[ $2 = "n" ]] - return ;; - esac - - # not found - return 127 + check_opt_array "$@" "${BUILDENV[@]}" } + ## # Checks to see if options are present in BUILDENV or PKGBUILD; # PKGBUILD options always take precedence. # # usage : check_buildoption( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_buildoption() { - in_opt_array "$1" ${options[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - in_opt_array "$1" ${BUILDENV[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # not found - return 127 + check_opt_array "$@" "${BUILDENV[@]}" "${options[@]}" } -- 2.17.1

1 5