From ScriptDevil at zoho.com  Thu Dec  2 07:11:19 2021
From: ScriptDevil at zoho.com (Ashok Gautham Jadatharan)
Date: Thu,  2 Dec 2021 12:41:19 +0530
Subject: [PATCH] Make unlocking error messages uniform
Message-ID: <20211202071119.11347-1-ScriptDevil@zoho.com>

Upon failing to unlock the database, pacman -Su provides a useful tip
related to unlocking it by deleting /var/lib/pacman/db.lck if it already
exists.
This fixes pacman -Syu to provide the same tip upon failing to lock.

Signed-off-by: Ashok Gautham Jadatharan <ScriptDevil at zoho.com>
---
 src/pacman/util.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/pacman/util.c b/src/pacman/util.c
index 0f50ae0b..d3422739 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -152,12 +152,25 @@ int sync_syncdbs(int level, alpm_list_t *syncs)
 {
 	int ret;
 	int force = (level < 2 ? 0 : 1);
+	alpm_errno_t err;
 
 	multibar_move_completed_up(false);
 	ret = alpm_db_update(config->handle, syncs, force);
+
 	if(ret < 0) {
+		err = alpm_errno(config->handle);
 		pm_printf(ALPM_LOG_ERROR, _("failed to synchronize all databases (%s)\n"),
-			alpm_strerror(alpm_errno(config->handle)));
+			alpm_strerror(err));
+
+		if(err == ALPM_ERR_HANDLE_LOCK) {
+			const char *lockfile = alpm_option_get_lockfile(config->handle);
+			pm_printf(ALPM_LOG_ERROR, _("could not lock database: %s\n"),
+						strerror(errno));
+			if(access(lockfile, F_OK) == 0) {
+				fprintf(stderr, _("  if you're sure a package manager is not already\n"
+							"  running, you can remove %s\n"), lockfile);
+			}
+		}
 	}
 
 	return (ret >= 0);
-- 
2.34.1


From allan at archlinux.org  Sun Dec 12 10:54:36 2021
From: allan at archlinux.org (Allan McRae)
Date: Sun, 12 Dec 2021 20:54:36 +1000
Subject: [PATCH] Replace libdepends/libprovides
Message-ID: <20211212105440.1129363-1-allan@archlinux.org>

This patch series replaces the old libdepends/libprovides system into
something akin to that used by APK.  In short, makepkg.conf will have
a variable like:

LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')

At the end of package building, makepkg will look in the library
directories and add a provide.  E.g. for pacman:

provide = lib:libalpm.so.13

Note the prefix matches the prefix given to the relevant directory in
LIB_DIRS.  Similarly, makepkg can add dependencies on libraries. E.g.
pacman may have:

depends = lib:libgpgme.so.11

Note, to help with bootstrapping this system, or if packages just do
not want to add libprovides, the depends entries are only added if a
package actually provides them.

This is different to the APK system for libraries which uses "so" as the
prefix and is not configurable.  But Alpine used musl, which has no
concept of multilib, so we need to be a bit more flexible.

The dependency/provides addotions can all be disabled in pacman.conf
with the '!autodeps' option.

Note that APK has similar things for binaries and pkg-config files. e.g.
provides = cmd:pacman
provides = pc:libalpm

These can readily be added as dropins to libmakepkg.

Allan McRae (4):
  makepkg: remove libdepends and libprovides
  libmakepkg: add framework for autodeps
  libmakepkg: automatically add library sonames to provides
  libmakepkg: automatically add library dependencies

 doc/PKGBUILD.5.asciidoc                       |   9 --
 doc/makepkg.conf.5.asciidoc                   |  11 ++
 etc/makepkg.conf.in                           |   8 +-
 scripts/libmakepkg/autodep.sh.in              |  38 ++++++
 .../libmakepkg/autodep/library_depends.sh.in  |  75 +++++++++++
 .../libmakepkg/autodep/library_provides.sh.in |  56 +++++++++
 scripts/libmakepkg/autodep/meson.build        |  18 +++
 scripts/libmakepkg/meson.build                |   1 +
 scripts/makepkg.sh.in                         | 119 +-----------------
 9 files changed, 206 insertions(+), 129 deletions(-)
 create mode 100644 scripts/libmakepkg/autodep.sh.in
 create mode 100644 scripts/libmakepkg/autodep/library_depends.sh.in
 create mode 100644 scripts/libmakepkg/autodep/library_provides.sh.in
 create mode 100644 scripts/libmakepkg/autodep/meson.build

-- 
2.34.1


From allan at archlinux.org  Sun Dec 12 10:54:37 2021
From: allan at archlinux.org (Allan McRae)
Date: Sun, 12 Dec 2021 20:54:37 +1000
Subject: [PATCH] makepkg: remove libdepends and libprovides
In-Reply-To: <20211212105440.1129363-1-allan@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
Message-ID: <20211212105440.1129363-2-allan@archlinux.org>

This will be replaced by a better system

Signed-off-by: Allan McRae <allan at archlinux.org>
---
 doc/PKGBUILD.5.asciidoc |   9 ---
 scripts/makepkg.sh.in   | 118 ----------------------------------------
 2 files changed, 127 deletions(-)

diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc
index dee15f5e..4ca8eb3b 100644
--- a/doc/PKGBUILD.5.asciidoc
+++ b/doc/PKGBUILD.5.asciidoc
@@ -187,11 +187,6 @@ contain whitespace characters.
 	than or equal to), `<=` (less than or equal to), `=` (equal to), `>`
 	(greater than), or `<` (less than).
 +
-If the dependency name appears to be a library (ends with .so), makepkg will
-try to find a binary that depends on the library in the built package and
-append the version needed by the binary. Appending the version yourself
-disables automatic detection.
-+
 Additional architecture-specific depends can be added by appending an
 underscore and the architecture name e.g., 'depends_x86_64=()'.
 
@@ -245,10 +240,6 @@ example, dcron can provide 'cron=2.0' to satisfy the 'cron>=2.0' dependency of
 other packages. Provisions involving the `>` and `<` operators are invalid as
 only specific versions of a package may be provided.
 +
-If the provision name appears to be a library (ends with .so), makepkg will
-try to find the library in the built package and append the correct
-version. Appending the version yourself disables automatic detection.
-+
 Additional architecture-specific provides can be added by appending an
 underscore and the architecture name e.g., 'provides_x86_64=()'.
 
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 3c7977db..639ea84a 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -463,121 +463,6 @@ run_package() {
 	run_function_safe "package${1:+_$1}"
 }
 
-find_libdepends() {
-	local d sodepends
-
-	sodepends=0
-	for d in "${depends[@]}"; do
-		if [[ $d = *.so ]]; then
-			sodepends=1
-			break
-		fi
-	done
-
-	if (( sodepends == 0 )); then
-		(( ${#depends[@]} )) && printf '%s\n' "${depends[@]}"
-		return 0
-	fi
-
-	local libdeps filename soarch sofile soname soversion
-	declare -A libdeps
-
-	while IFS= read -rd '' filename; do
-		# get architecture of the file; if soarch is empty it's not an ELF binary
-		soarch=$(LC_ALL=C readelf -h "$filename" 2>/dev/null | sed -n 's/.*Class.*ELF\(32\|64\)/\1/p')
-		[[ -n "$soarch" ]] || continue
-
-		# process all libraries needed by the binary
-		for sofile in $(LC_ALL=C readelf -d "$filename" 2>/dev/null | sed -nr 's/.*Shared library: \[(.*)\].*/\1/p')
-		do
-			# extract the library name: libfoo.so
-			soname="${sofile%.so?(+(.+([0-9])))}".so
-			# extract the major version: 1
-			soversion="${sofile##*\.so\.}"
-
-			if [[ ${libdeps[$soname]} ]]; then
-				if [[ ${libdeps[$soname]} != *${soversion}-${soarch}* ]]; then
-					libdeps[$soname]+=" ${soversion}-${soarch}"
-				fi
-			else
-				libdeps[$soname]="${soversion}-${soarch}"
-			fi
-		done
-	done < <(find "$pkgdir" -type f -perm -u+x -print0)
-
-	local libdepends v
-	for d in "${depends[@]}"; do
-		case "$d" in
-			*.so)
-				if [[ ${libdeps[$d]} ]]; then
-					for v in ${libdeps[$d]}; do
-						libdepends+=("$d=$v")
-					done
-				else
-					warning "$(gettext "Library listed in %s is not required by any files: %s")" "'depends'" "$d"
-					libdepends+=("$d")
-				fi
-				;;
-			*)
-				libdepends+=("$d")
-				;;
-		esac
-	done
-
-	(( ${#libdepends[@]} )) && printf '%s\n' "${libdepends[@]}"
-}
-
-
-find_libprovides() {
-	local p versioned_provides libprovides missing
-	for p in "${provides[@]}"; do
-		missing=0
-		versioned_provides=()
-		case "$p" in
-			*.so)
-				mapfile -t filename < <(find "$pkgdir" -type f -name $p\* | LC_ALL=C sort)
-				if [[ $filename ]]; then
-					# packages may provide multiple versions of the same library
-					for fn in "${filename[@]}"; do
-						# check if we really have a shared object
-						if LC_ALL=C readelf -h "$fn" 2>/dev/null | grep -q '.*Type:.*DYN (Shared object file).*'; then
-							# get the string binaries link to (e.g. libfoo.so.1.2 -> libfoo.so.1)
-							local sofile=$(LC_ALL=C readelf -d "$fn" 2>/dev/null | sed -n 's/.*Library soname: \[\(.*\)\].*/\1/p')
-							if [[ -z "$sofile" ]]; then
-								warning "$(gettext "Library listed in %s is not versioned: %s")" "'provides'" "$p"
-								continue
-							fi
-
-							# get the library architecture (32 or 64 bit)
-							local soarch=$(LC_ALL=C readelf -h "$fn" | sed -n 's/.*Class.*ELF\(32\|64\)/\1/p')
-
-							# extract the library major version
-							local soversion="${sofile##*\.so\.}"
-
-							versioned_provides+=("${p}=${soversion}-${soarch}")
-						else
-							warning "$(gettext "Library listed in %s is not a shared object: %s")" "'provides'" "$p"
-						fi
-					done
-				else
-					missing=1
-				fi
-				;;
-		esac
-
-		if (( missing )); then
-			warning "$(gettext "Cannot find library listed in %s: %s")" "'provides'" "$p"
-		fi
-		if (( ${#versioned_provides[@]} > 0 )); then
-			libprovides+=("${versioned_provides[@]}")
-		else
-			libprovides+=("$p")
-		fi
-	done
-
-	(( ${#libprovides[@]} )) && printf '%s\n' "${libprovides[@]}"
-}
-
 write_kv_pair() {
 	local key="$1"
 	shift
@@ -617,9 +502,6 @@ write_pkginfo() {
 	write_kv_pair "size" "$size"
 	write_kv_pair "arch" "$pkgarch"
 
-	mapfile -t provides < <(find_libprovides)
-	mapfile -t depends < <(find_libdepends)
-
 	write_kv_pair "license"     "${license[@]}"
 	write_kv_pair "replaces"    "${replaces[@]}"
 	write_kv_pair "group"       "${groups[@]}"
-- 
2.34.1


From allan at archlinux.org  Sun Dec 12 10:54:38 2021
From: allan at archlinux.org (Allan McRae)
Date: Sun, 12 Dec 2021 20:54:38 +1000
Subject: [PATCH] libmakepkg: add framework for autodeps
In-Reply-To: <20211212105440.1129363-1-allan@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
Message-ID: <20211212105440.1129363-3-allan@archlinux.org>

Signed-off-by: Allan McRae <allan at archlinux.org>
---
 etc/makepkg.conf.in              |  6 +++--
 scripts/libmakepkg/autodep.sh.in | 38 ++++++++++++++++++++++++++++++++
 scripts/makepkg.sh.in            |  1 +
 3 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100644 scripts/libmakepkg/autodep.sh.in

diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in
index 5ad3d490..f69a7add 100644
--- a/etc/makepkg.conf.in
+++ b/etc/makepkg.conf.in
@@ -76,7 +76,8 @@ BUILDENV=(!distcc color !ccache check !sign)
 #   These are default values for the options=() settings
 #########################################################################
 #
-# Makepkg defaults: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug !lto)
+# Makepkg defaults:
+# OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug !lto !autodeps)
 #  A negated option will do the opposite of the comments below.
 #
 #-- strip:      Strip symbols from binaries/libraries
@@ -88,8 +89,9 @@ BUILDENV=(!distcc color !ccache check !sign)
 #-- purge:      Remove files specified by PURGE_TARGETS
 #-- debug:      Add debugging flags as specified in DEBUG_* variables
 #-- lto:        Add compile flags for building with link time optimization
+#-- autodeps:   Automatically add depends/provides
 #
-OPTIONS=(strip docs libtool staticlibs emptydirs zipman purge !debug !lto)
+OPTIONS=(strip docs libtool staticlibs emptydirs zipman purge !debug !lto !autodeps)
 
 #-- File integrity checks to use. Valid: ck, md5, sha1, sha224, sha256, sha384, sha512, b2
 INTEGRITY_CHECK=(ck)
diff --git a/scripts/libmakepkg/autodep.sh.in b/scripts/libmakepkg/autodep.sh.in
new file mode 100644
index 00000000..80f66e70
--- /dev/null
+++ b/scripts/libmakepkg/autodep.sh.in
@@ -0,0 +1,38 @@
+#!/bin/bash
+#
+#   autodep.sh - functions for automatically adding depends/provides
+#
+#   Copyright (c) 2021 Pacman Development Team <pacman-dev at lists.archlinux.org>
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+
+[[ -n "$LIBMAKEPKG_AUTODEP_SH" ]] && return
+LIBMAKEPKG_AUTODEP_SH=1
+
+LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
+
+declare -a autodep_functions
+
+for lib in "$LIBRARY/autodep/"*.sh; do
+	source "$lib"
+done
+
+readonly -a autodep_functions
+
+generate_autodeps() {
+	for func in ${autodep_functions[@]}; do
+		$func
+	done
+}
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 639ea84a..818eb471 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -480,6 +480,7 @@ write_pkginfo() {
 	local size=$(dirsize)
 
 	merge_arch_attrs
+	generate_autodeps
 
 	printf "# Generated by makepkg %s\n" "$makepkg_version"
 	printf "# using %s\n" "$(fakeroot -v)"
-- 
2.34.1


From allan at archlinux.org  Sun Dec 12 10:54:39 2021
From: allan at archlinux.org (Allan McRae)
Date: Sun, 12 Dec 2021 20:54:39 +1000
Subject: [PATCH] libmakepkg: automatically add library sonames to provides
In-Reply-To: <20211212105440.1129363-1-allan@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
Message-ID: <20211212105440.1129363-4-allan@archlinux.org>

When the option "autodeps" is enabled, makepkg will add provides
entries for libraries found in the directories specified in LIB_DIRS
in makepkg.conf.  The entries LIB_DIRS array have the format
"prefix:directory".  For example, the entry "lib:usr/lib" will search
$pkgdir/usr/lib for library sonames and add "lib:libfoo.so.1" to the
provides array.

Signed-off-by: Allan McRae <allan at archlinux.org>
---
 doc/makepkg.conf.5.asciidoc                   | 11 ++++
 etc/makepkg.conf.in                           |  2 +
 .../libmakepkg/autodep/library_provides.sh.in | 56 +++++++++++++++++++
 scripts/libmakepkg/autodep/meson.build        | 18 ++++++
 scripts/libmakepkg/meson.build                |  1 +
 5 files changed, 88 insertions(+)
 create mode 100644 scripts/libmakepkg/autodep/library_provides.sh.in
 create mode 100644 scripts/libmakepkg/autodep/meson.build

diff --git a/doc/makepkg.conf.5.asciidoc b/doc/makepkg.conf.5.asciidoc
index 76c27f6a..39c5c808 100644
--- a/doc/makepkg.conf.5.asciidoc
+++ b/doc/makepkg.conf.5.asciidoc
@@ -193,6 +193,11 @@ Options
 		Enable building packages using link time optimization. Adds '-flto'
 		to both CFLAGS and CXXFLAGS.
 
+	*autodep*;;
+		Enable the automatic addition of libraries to the depends and
+		provides arrays. Search library directories are controlled by
+		the LIB_DIRS variable defined below.
+
 **INTEGRITY_CHECK=(**check1 ...**)**::
 	File integrity checks to use. Multiple checks may be specified; this
 	affects both generation and checking. The current valid options are:
@@ -223,6 +228,12 @@ Options
 	that are located in opt/, you may need to add the directory to this
 	array. *NOTE:* Do not add the leading slash to the directory name.
 
+**LIB_DIRS=(**lib:usr/lib ...**)**::
+	If `autodeps` is specified in the `OPTIONS` array, this variable will
+	instruct makepkg where to look to find librarys to add to the `provides`
+	array. The format is "prefix:path", where provides will be added for
+	libraries found in "path" with the specified prefix added.
+
 **PURGE_TARGETS=(**usr/{,share}/info/dir .podlist *.pod...**)**::
 	If `purge` is specified in the `OPTIONS` array, this variable will
 	instruct makepkg which files to remove from the package. This is
diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in
index f69a7add..0c911cce 100644
--- a/etc/makepkg.conf.in
+++ b/etc/makepkg.conf.in
@@ -109,6 +109,8 @@ DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
 PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)
 #-- Directory to store source code in for debug packages
 DBGSRCDIR="/usr/src/debug"
+#-- Prefix and directories for library autodeps
+LIB_DIRS=('lib:/usr/lib' 'lib32:/usr/lib32')
 
 #########################################################################
 # PACKAGE OUTPUT
diff --git a/scripts/libmakepkg/autodep/library_provides.sh.in b/scripts/libmakepkg/autodep/library_provides.sh.in
new file mode 100644
index 00000000..5cd497fa
--- /dev/null
+++ b/scripts/libmakepkg/autodep/library_provides.sh.in
@@ -0,0 +1,56 @@
+#!/bin/bash
+#
+#   library_provides.sh - Automatically add a packages libraries to provides
+#
+#   Copyright (c) 2021 Pacman Development Team <pacman-dev at lists.archlinux.org>
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+
+[[ -n "$LIBMAKEPKG_AUTODEP_LIBRARY_PROVIDES_SH" ]] && return
+LIBMAKEPKG_AUTODEP_LIBRARY_PROVIDES_SH=1
+
+LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
+
+autodep_functions+=('library_provides')
+
+library_provides() {
+	if check_option "autodeps" "y"; then
+		for lib in ${LIB_DIRS[@]}; do
+			dir=${lib/*:}
+			prefix=${lib/:*}
+
+			if [[ ! -d "$pkgdir/$dir" ]]; then
+				continue;
+			fi
+
+			mapfile -t filenames < <(find "$pkgdir/$dir" -type f | LC_ALL=C sort)
+
+			for fn in "${filenames[@]}"; do
+				# check we have a shared library
+				if LC_ALL=C readelf -h "$fn" 2>/dev/null | grep -q '.*Type:.*DYN (Shared object file).*'; then
+					# extract library soname
+					local sofile=$(LC_ALL=C readelf -d "$fn" 2>/dev/null | sed -n 's/.*Library soname: \[\(.*\)\].*/\1/p')
+
+					if [[ -z "$sofile" ]]; then
+						# the library is not versioned
+						continue
+					fi
+
+					provides+=("$prefix:$sofile")
+				fi
+			done
+		done
+	fi
+}
diff --git a/scripts/libmakepkg/autodep/meson.build b/scripts/libmakepkg/autodep/meson.build
new file mode 100644
index 00000000..e0af26a6
--- /dev/null
+++ b/scripts/libmakepkg/autodep/meson.build
@@ -0,0 +1,18 @@
+libmakepkg_module = 'tidy'
+
+sources = [
+  'library_provides.sh.in',
+
+]
+
+foreach src : sources
+  output_dir = join_paths(get_option('datadir'), 'makepkg', libmakepkg_module)
+
+  custom_target(
+    libmakepkg_module + '_' + src.underscorify(),
+    command : [ SCRIPT_EDITOR, '@INPUT@', '@OUTPUT@' ],
+    input : src,
+    output : '@BASENAME@',
+    install : true,
+    install_dir : output_dir)
+endforeach
diff --git a/scripts/libmakepkg/meson.build b/scripts/libmakepkg/meson.build
index 50eb905b..6e83a4a8 100644
--- a/scripts/libmakepkg/meson.build
+++ b/scripts/libmakepkg/meson.build
@@ -1,4 +1,5 @@
 libmakepkg_modules = [
+  { 'name' : 'autodep',       'has_subdir' : true },
   { 'name' : 'buildenv',      'has_subdir' : true },
   { 'name' : 'executable',    'has_subdir' : true },
   { 'name' : 'integrity',     'has_subdir' : true },
-- 
2.34.1


From allan at archlinux.org  Sun Dec 12 10:54:40 2021
From: allan at archlinux.org (Allan McRae)
Date: Sun, 12 Dec 2021 20:54:40 +1000
Subject: [PATCH] libmakepkg: automatically add library dependencies
In-Reply-To: <20211212105440.1129363-1-allan@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
Message-ID: <20211212105440.1129363-5-allan@archlinux.org>

Add linked libraries to a packages dependency list. This is the partner
to automatically generated library provides, and thus depends take the
same format. To help with bootstrapping, library dependencies are only
added if the relevant provide exists.

Signed-off-by: Allan McRae <allan at archlinux.org>
---
 .../libmakepkg/autodep/library_depends.sh.in  | 75 +++++++++++++++++++
 scripts/libmakepkg/autodep/meson.build        |  2 +-
 2 files changed, 76 insertions(+), 1 deletion(-)
 create mode 100644 scripts/libmakepkg/autodep/library_depends.sh.in

diff --git a/scripts/libmakepkg/autodep/library_depends.sh.in b/scripts/libmakepkg/autodep/library_depends.sh.in
new file mode 100644
index 00000000..4c387241
--- /dev/null
+++ b/scripts/libmakepkg/autodep/library_depends.sh.in
@@ -0,0 +1,75 @@
+#!/bin/bash
+#
+#   library_depends.sh - Automatically add library requirements to depends
+#
+#   Copyright (c) 2021 Pacman Development Team <pacman-dev at lists.archlinux.org>
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+
+[[ -n "$LIBMAKEPKG_AUTODEP_LIBRARY_DEPENDS_SH" ]] && return
+LIBMAKEPKG_AUTODEP_LIBRARY_DEPENDS_SH=1
+
+LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
+
+autodep_functions+=('library_depends')
+
+library_depends() {
+	if check_option "autodeps" "y"; then
+		local dep filename libdeps libdir libpath prefix sofile
+		declare -a libdeps
+
+		while IFS= read -rd '' filename; do
+			for sofile in $(LC_ALL=C readelf -d $filename 2>/dev/null | sed -nr 's/.*Shared library: \[(.*)\].*/\1/p'); do
+				# get the full path of the library
+				libpath=$(ldd $filename | sed -nr "s/.$sofile => (.*) \(.*\)/\1/p")
+
+				# if ldd can not find the library, it is likely part of the package and not in filesystem
+				if [[ -z $libpath ]]; then
+					continue
+				fi
+
+				# skip if the library is part of the package
+				if [[ -e "$pkgdir/$libpath" ]]; then
+					continue
+				fi
+
+				# find the prefix for the dependency
+				libpath=${libpath#/}
+				libpath=${libpath%/*}
+
+				unset prefix
+				for libdir in ${LIB_DIRS[@]}; do
+					if [[ ${libdir/*:} == ${libpath} ]]; then
+						prefix=${libdir/:*}
+					fi
+				done
+
+				if [[ -z ${prefix} ]]; then
+					continue
+				fi
+
+				# only add library dependency if it exists - this helps bootstraping dependencies
+				if [[ $(run_pacman -T "$prefix:$sofile") ]]; then
+					continue
+				fi
+
+				libdeps+=("$prefix:$sofile")
+			done
+
+		done < <(find "$pkgdir" -type f -perm -u+x -print0)
+
+		depends+=($(printf '%s\n' "${libdeps[@]}" | LC_ALL=C sort -u))
+	fi
+}
diff --git a/scripts/libmakepkg/autodep/meson.build b/scripts/libmakepkg/autodep/meson.build
index e0af26a6..08c4c818 100644
--- a/scripts/libmakepkg/autodep/meson.build
+++ b/scripts/libmakepkg/autodep/meson.build
@@ -1,8 +1,8 @@
 libmakepkg_module = 'tidy'
 
 sources = [
+  'library_depends.sh.in',
   'library_provides.sh.in',
-
 ]
 
 foreach src : sources
-- 
2.34.1


From emil.l.velikov at gmail.com  Tue Dec 14 10:40:30 2021
From: emil.l.velikov at gmail.com (Emil Velikov)
Date: Tue, 14 Dec 2021 10:40:30 +0000
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <20211212105440.1129363-1-allan@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
Message-ID: <CACvgo524RSyMggMw6OtvRtH=jPwXDCtnJmvwhAgS8x1OcHVDww@mail.gmail.com>

Hey Allan,

I really like the idea, although I might have spotted some gotchas.

On Sun, 12 Dec 2021 at 10:54, Allan McRae <allan at archlinux.org> wrote:
>
> This patch series replaces the old libdepends/libprovides system into
> something akin to that used by APK.  In short, makepkg.conf will have
> a variable like:
>
> LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
>
Considering your examples (below) also handle "cmd" and "pc" the
LIB_DIRS name is misleading. Alas no better suggestion comes to mind
ATM.

> At the end of package building, makepkg will look in the library
> directories and add a provide.  E.g. for pacman:
>
> provide = lib:libalpm.so.13
>
If I understand correctly, we create a mapping pretty-name:actual-path
in the makepkg.conf and use the pretty-name in PKGBUILD.

Do we add the pretty-name or actual-path in .PKGINFO? Does pacman
print these autodeps ... even if only for informational purposes?
What is expected to happen if someone typos the existing mappings -
say "lib32:usr/lib23"? Or re-defines the standard ones
"lib:my/special/path"?
Are we going to continue or error out - is the error message going to
be meaningful or rather cryptic?

> Note the prefix matches the prefix given to the relevant directory in
> LIB_DIRS.  Similarly, makepkg can add dependencies on libraries. E.g.
> pacman may have:
>
> depends = lib:libgpgme.so.11
>
> Note, to help with bootstrapping this system, or if packages just do
> not want to add libprovides, the depends entries are only added if a
> package actually provides them.
>
> This is different to the APK system for libraries which uses "so" as the
> prefix and is not configurable.  But Alpine used musl, which has no
> concept of multilib, so we need to be a bit more flexible.
>
I think the above questions might be the reason why Alpine chose to
keep them hard-coded. In particular, while this approach provides
flexibility, it leaves things open to various mistakes and misuse.

Off the top of my head, we can enhance makepkg to catch most of those
issues. For example - we can use the actual-path in .PKGINFO,
explicitly check for mistakes/changes in the default mappings - lib,
lib32...
Although at this point one might as well have the defaults hardcoded in makepkg?

> The dependency/provides addotions can all be disabled in pacman.conf
> with the '!autodeps' option.
>
s/addotions/additions/;s/pacman.conf/makepkg.conf/ typos?

At a glance we can disable autodeps in the PKGBUILD itself, right?

HTH
Emil

From allan at archlinux.org  Tue Dec 14 11:28:13 2021
From: allan at archlinux.org (Allan McRae)
Date: Tue, 14 Dec 2021 21:28:13 +1000
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <CACvgo524RSyMggMw6OtvRtH=jPwXDCtnJmvwhAgS8x1OcHVDww@mail.gmail.com>
References: <20211212105440.1129363-1-allan@archlinux.org>
 <CACvgo524RSyMggMw6OtvRtH=jPwXDCtnJmvwhAgS8x1OcHVDww@mail.gmail.com>
Message-ID: <49e977e1-29fe-81e3-eb7a-5e5e0e47377e@archlinux.org>

On 14/12/21 20:40, Emil Velikov wrote:
> Hey Allan,
> 
> I really like the idea, although I might have spotted some gotchas.
> 
> On Sun, 12 Dec 2021 at 10:54, Allan McRae <allan at archlinux.org> wrote:
>>
>> This patch series replaces the old libdepends/libprovides system into
>> something akin to that used by APK.  In short, makepkg.conf will have
>> a variable like:
>>
>> LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
>>
> Considering your examples (below) also handle "cmd" and "pc" the
> LIB_DIRS name is misleading. Alas no better suggestion comes to mind
> ATM.

Not really...  This is the path for adding library dependencies & 
provides.  If other autodeps get added, they may need their own 
configuration option.

>> At the end of package building, makepkg will look in the library
>> directories and add a provide.  E.g. for pacman:
>>
>> provide = lib:libalpm.so.13
>>
> If I understand correctly, we create a mapping pretty-name:actual-path
> in the makepkg.conf and use the pretty-name in PKGBUILD.
> 
> Do we add the pretty-name or actual-path in .PKGINFO? 

That is the line from the .PKGINFO

provide = <tag>:<soname>

Does pacman
> print these autodeps ... even if only for informational purposes?

They are treated the same as any provide or depend.

For example, using -Qi on my pacman-git package currently shows:

Provides        : pacman=6.0.1  lib:libalpm.so.13
Depends On      : archlinux-keyring  bash  curl  gpgme  libarchive
                   pacman-mirrorlist  lib:libcurl.so.4

> What is expected to happen if someone typos the existing mappings -
> say "lib32:usr/lib23"? Or re-defines the standard ones
> "lib:my/special/path"?

It their makepkg.conf has "lib32:usr/lib23" it is very likely that no 
dependencies/provides will be added.

> Are we going to continue or error out - is the error message going to
> be meaningful or rather cryptic?

As above, nothing will happen.  The usr/lib23 directory will (I guess) 
never occur in a package, so never be searched for files with an soname.

I see this as being the same as any other configuration typo.  e.g. if 
MAN_DIRS pointed to non-existent places, no man pages would be compressed.

>> Note the prefix matches the prefix given to the relevant directory in
>> LIB_DIRS.  Similarly, makepkg can add dependencies on libraries. E.g.
>> pacman may have:
>>
>> depends = lib:libgpgme.so.11
>>
>> Note, to help with bootstrapping this system, or if packages just do
>> not want to add libprovides, the depends entries are only added if a
>> package actually provides them.
>>
>> This is different to the APK system for libraries which uses "so" as the
>> prefix and is not configurable.  But Alpine used musl, which has no
>> concept of multilib, so we need to be a bit more flexible.
>>
> I think the above questions might be the reason why Alpine chose to
> keep them hard-coded. In particular, while this approach provides
> flexibility, it leaves things open to various mistakes and misuse.

MAN_DIRS, DOC_DIRS, PURGE_TARGETS, ...   all could have typos in their 
configuration and not work.

> Off the top of my head, we can enhance makepkg to catch most of those
> issues. For example - we can use the actual-path in .PKGINFO,
> explicitly check for mistakes/changes in the default mappings - lib,
> lib32...
> Although at this point one might as well have the defaults hardcoded in makepkg?

This needs to be configurable.  e.g. some distros will have:

LIB_DIRS=('so:lib' 'so:usr/lib')

when they have not done a /usr merge.

Note, I selected the "so" prefix as being clearer for that example.  I'm 
thinking "so:usr/lib" and "so32:usr/lib32" might be better for the 
configuration example.

>> The dependency/provides addotions can all be disabled in pacman.conf
>> with the '!autodeps' option.
>>
> s/addotions/additions/;s/pacman.conf/makepkg.conf/ typos?

Yes - I meant the OPTIONS array in makepkg.conf.

> At a glance we can disable autodeps in the PKGBUILD itself, right?
> 

Yes - it is can be specified in options=().

Thanks for the comments.

Allan

From heftig at archlinux.org  Tue Dec 14 11:51:19 2021
From: heftig at archlinux.org (Jan Alexander Steffens (heftig))
Date: Tue, 14 Dec 2021 12:51:19 +0100
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <20211212105440.1129363-1-allan@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
Message-ID: <CAMQ-g0fiti_b38q_E+urzo9GyZ2BqCymjDDVJ=FYsJoVrU4wcg@mail.gmail.com>

On Sun, Dec 12, 2021 at 11:54 AM Allan McRae <allan at archlinux.org> wrote:

> This patch series replaces the old libdepends/libprovides system into
> something akin to that used by APK.  In short, makepkg.conf will have
> a variable like:
>
> LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
>

What about packages that install libraries into non-standard dirs and then
configure ld.so to look?

On my system I currently have:

/usr/lib/libfakeroot
/usr/lib/opencollada
/usr/lib/openmpi
/usr/lib/perf

Can this somehow be covered? I guess ignoring it wouldn't leave us any
worse off.

From allan at archlinux.org  Tue Dec 14 12:10:43 2021
From: allan at archlinux.org (Allan McRae)
Date: Tue, 14 Dec 2021 22:10:43 +1000
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <CAMQ-g0fiti_b38q_E+urzo9GyZ2BqCymjDDVJ=FYsJoVrU4wcg@mail.gmail.com>
References: <20211212105440.1129363-1-allan@archlinux.org>
 <CAMQ-g0fiti_b38q_E+urzo9GyZ2BqCymjDDVJ=FYsJoVrU4wcg@mail.gmail.com>
Message-ID: <dbcf8a41-6e38-99e0-099a-af5a11c31612@archlinux.org>

On 14/12/21 21:51, Jan Alexander Steffens (heftig) wrote:
> On Sun, Dec 12, 2021 at 11:54 AM Allan McRae <allan at archlinux.org 
> <mailto:allan at archlinux.org>> wrote:
> 
>     This patch series replaces the old libdepends/libprovides system into
>     something akin to that used by APK.? In short, makepkg.conf will have
>     a variable like:
> 
>     LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
> 
> 
> What about packages that install libraries into non-standard dirs and 
> then configure ld.so to look?
> 
> On my system I currently have:
> 
> /usr/lib/libfakeroot
> /usr/lib/opencollada
> /usr/lib/openmpi
> /usr/lib/perf
> 
> Can this somehow be covered? I guess ignoring it wouldn't leave us any 
> worse off.

Sure.  E.g. the fakeroot PKGBUILD can add:

LIB_DIRS+=('lib:usr/lib/libfakeroot')

and lib:libfakeroot-0.so will be added as a provide.

From emil.l.velikov at gmail.com  Tue Dec 14 12:28:41 2021
From: emil.l.velikov at gmail.com (Emil Velikov)
Date: Tue, 14 Dec 2021 12:28:41 +0000
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <49e977e1-29fe-81e3-eb7a-5e5e0e47377e@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
 <CACvgo524RSyMggMw6OtvRtH=jPwXDCtnJmvwhAgS8x1OcHVDww@mail.gmail.com>
 <49e977e1-29fe-81e3-eb7a-5e5e0e47377e@archlinux.org>
Message-ID: <CACvgo53A1jEZ=8DXbii-=Yt83R+a8UbVLmewHY-9GFNneKkPAQ@mail.gmail.com>

On Tue, 14 Dec 2021 at 11:28, Allan McRae <allan at archlinux.org> wrote:
>
> On 14/12/21 20:40, Emil Velikov wrote:
> > Hey Allan,
> >
> > I really like the idea, although I might have spotted some gotchas.
> >
> > On Sun, 12 Dec 2021 at 10:54, Allan McRae <allan at archlinux.org> wrote:
> >>
> >> This patch series replaces the old libdepends/libprovides system into
> >> something akin to that used by APK.  In short, makepkg.conf will have
> >> a variable like:
> >>
> >> LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
> >>
> > Considering your examples (below) also handle "cmd" and "pc" the
> > LIB_DIRS name is misleading. Alas no better suggestion comes to mind
> > ATM.
>
> Not really...  This is the path for adding library dependencies &
> provides.  If other autodeps get added, they may need their own
> configuration option.
>

This sounds great.

[snip]

> > Are we going to continue or error out - is the error message going to
> > be meaningful or rather cryptic?
>
> As above, nothing will happen.  The usr/lib23 directory will (I guess)
> never occur in a package, so never be searched for files with an soname.
>
We might want to have a simple check in makepkg, to high-light those.
If PKGBUILD has "provides" to a non-existant file, we could error out IMHO.

This will catch both typos on the packaging side as well as buggy
upstream - say they dropped/renamed the library, or a particular
configure combination no longer builds one of the dozen+ DSOs.

This is not a blocking suggestion, but I can see it as quite beneficial.

[snip]
> > Although at this point one might as well have the defaults hardcoded in makepkg?
>
> This needs to be configurable.  e.g. some distros will have:
>
> LIB_DIRS=('so:lib' 'so:usr/lib')
>
> when they have not done a /usr merge.
>

Agreed. When I said hard-coded I was thinking of a default, which can
be overwritten during build time. Say something like:
meson -D lib_dirs="lib:lib64/, lib32:lib/" ...

Thanks for elevating my concerns o/

-Emil

From allan at archlinux.org  Tue Dec 14 12:38:47 2021
From: allan at archlinux.org (Allan McRae)
Date: Tue, 14 Dec 2021 22:38:47 +1000
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <CACvgo53A1jEZ=8DXbii-=Yt83R+a8UbVLmewHY-9GFNneKkPAQ@mail.gmail.com>
References: <20211212105440.1129363-1-allan@archlinux.org>
 <CACvgo524RSyMggMw6OtvRtH=jPwXDCtnJmvwhAgS8x1OcHVDww@mail.gmail.com>
 <49e977e1-29fe-81e3-eb7a-5e5e0e47377e@archlinux.org>
 <CACvgo53A1jEZ=8DXbii-=Yt83R+a8UbVLmewHY-9GFNneKkPAQ@mail.gmail.com>
Message-ID: <abb404f3-5a73-e34f-df69-6c4ea6a622ea@archlinux.org>

On 14/12/21 22:28, Emil Velikov wrote:
> On Tue, 14 Dec 2021 at 11:28, Allan McRae <allan at archlinux.org> wrote:
>>
>> On 14/12/21 20:40, Emil Velikov wrote:
>>> Hey Allan,
>>>
>>> I really like the idea, although I might have spotted some gotchas.
>>>
>>> On Sun, 12 Dec 2021 at 10:54, Allan McRae <allan at archlinux.org> wrote:
>>>>
>>>> This patch series replaces the old libdepends/libprovides system into
>>>> something akin to that used by APK.  In short, makepkg.conf will have
>>>> a variable like:
>>>>
>>>> LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
>>>>
>>> Considering your examples (below) also handle "cmd" and "pc" the
>>> LIB_DIRS name is misleading. Alas no better suggestion comes to mind
>>> ATM.
>>
>> Not really...  This is the path for adding library dependencies &
>> provides.  If other autodeps get added, they may need their own
>> configuration option.
>>
> 
> This sounds great.
> 
> [snip]
> 
>>> Are we going to continue or error out - is the error message going to
>>> be meaningful or rather cryptic?
>>
>> As above, nothing will happen.  The usr/lib23 directory will (I guess)
>> never occur in a package, so never be searched for files with an soname.
>>
> We might want to have a simple check in makepkg, to high-light those.
> If PKGBUILD has "provides" to a non-existant file, we could error out IMHO.
 >
> This will catch both typos on the packaging side as well as buggy
> upstream - say they dropped/renamed the library, or a particular
> configure combination no longer builds one of the dozen+ DSOs.
> 

I don't understand this suggestion. There would be no non-existent 
provide, as makepkg would not add one unless it finds one in the 
configured path.  This is a complete change from the current system 
where the name of the library needed to be in the PKGBUILD.  Now makepkg 
will automatically detect and add these values.

And we can't distinguish between a package that has no libraries to be 
provided and a makepkg.conf with a typo pointing to the wrong directory.

> This is not a blocking suggestion, but I can see it as quite beneficial.
> 
> [snip]
>>> Although at this point one might as well have the defaults hardcoded in makepkg?
>>
>> This needs to be configurable.  e.g. some distros will have:
>>
>> LIB_DIRS=('so:lib' 'so:usr/lib')
>>
>> when they have not done a /usr merge.
>>
> 
> Agreed. When I said hard-coded I was thinking of a default, which can
> be overwritten during build time. Say something like:
> meson -D lib_dirs="lib:lib64/, lib32:lib/" ...

I'm going to suggest the default is not to have this feature running at 
all.  So blank is a good default!  Or course each distro will provide a 
suitable makepkg.conf with their opinionated configuration.

A

From johannes at kyriasis.com  Tue Dec 14 12:39:41 2021
From: johannes at kyriasis.com (Johannes =?iso-8859-1?q?L=F6thberg?=)
Date: Tue, 14 Dec 2021 13:39:41 +0100
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <dbcf8a41-6e38-99e0-099a-af5a11c31612@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
 <CAMQ-g0fiti_b38q_E+urzo9GyZ2BqCymjDDVJ=FYsJoVrU4wcg@mail.gmail.com>
 <dbcf8a41-6e38-99e0-099a-af5a11c31612@archlinux.org>
Message-ID: <1639485244.vbfeqrxlt0.remmy@hydrogen.kyriasis.com>

Excerpts from Allan McRae's message of December 14, 2021 13:10:
> On 14/12/21 21:51, Jan Alexander Steffens (heftig) wrote:
>> On Sun, Dec 12, 2021 at 11:54 AM Allan McRae <allan at archlinux.org 
>> <mailto:allan at archlinux.org>> wrote:
>> 
>>     This patch series replaces the old libdepends/libprovides system into
>>     something akin to that used by APK.? In short, makepkg.conf will have
>>     a variable like:
>> 
>>     LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
>> 
>> 
>> What about packages that install libraries into non-standard dirs and 
>> then configure ld.so to look?
>> 
>> On my system I currently have:
>> 
>> /usr/lib/libfakeroot
>> /usr/lib/opencollada
>> /usr/lib/openmpi
>> /usr/lib/perf
>> 
>> Can this somehow be covered? I guess ignoring it wouldn't leave us any 
>> worse off.
> 
> Sure.  E.g. the fakeroot PKGBUILD can add:
> 
> LIB_DIRS+=('lib:usr/lib/libfakeroot')
> 
> and lib:libfakeroot-0.so will be added as a provide.
> 

With the currently proposed patch it should already be added even 
without touching LIB_DIRS, since the `find` command used doesn't limit 
the depth.  And adding it to LIB_DIRS would cause it to be added to 
provides= twice, unless the list is filtered later on in makepkg.

They just won't be added to depends= automatically unless added to LIB_DIRS.

-- 
Sincerely,
  Johannes L?thberg :: SA0DEM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 1727 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20211214/34a7210e/attachment.sig>

From emil.l.velikov at gmail.com  Tue Dec 14 12:48:34 2021
From: emil.l.velikov at gmail.com (Emil Velikov)
Date: Tue, 14 Dec 2021 12:48:34 +0000
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <abb404f3-5a73-e34f-df69-6c4ea6a622ea@archlinux.org>
References: <20211212105440.1129363-1-allan@archlinux.org>
 <CACvgo524RSyMggMw6OtvRtH=jPwXDCtnJmvwhAgS8x1OcHVDww@mail.gmail.com>
 <49e977e1-29fe-81e3-eb7a-5e5e0e47377e@archlinux.org>
 <CACvgo53A1jEZ=8DXbii-=Yt83R+a8UbVLmewHY-9GFNneKkPAQ@mail.gmail.com>
 <abb404f3-5a73-e34f-df69-6c4ea6a622ea@archlinux.org>
Message-ID: <CACvgo50L_GKo1oRte7SrQrH1nODZkLJbGaXOsdn_404P281Eog@mail.gmail.com>

On Tue, 14 Dec 2021 at 12:38, Allan McRae <allan at archlinux.org> wrote:
>
> On 14/12/21 22:28, Emil Velikov wrote:
> > On Tue, 14 Dec 2021 at 11:28, Allan McRae <allan at archlinux.org> wrote:
> >>
> >> On 14/12/21 20:40, Emil Velikov wrote:
> >>> Hey Allan,
> >>>
> >>> I really like the idea, although I might have spotted some gotchas.
> >>>
> >>> On Sun, 12 Dec 2021 at 10:54, Allan McRae <allan at archlinux.org> wrote:
> >>>>
> >>>> This patch series replaces the old libdepends/libprovides system into
> >>>> something akin to that used by APK.  In short, makepkg.conf will have
> >>>> a variable like:
> >>>>
> >>>> LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
> >>>>
> >>> Considering your examples (below) also handle "cmd" and "pc" the
> >>> LIB_DIRS name is misleading. Alas no better suggestion comes to mind
> >>> ATM.
> >>
> >> Not really...  This is the path for adding library dependencies &
> >> provides.  If other autodeps get added, they may need their own
> >> configuration option.
> >>
> >
> > This sounds great.
> >
> > [snip]
> >
> >>> Are we going to continue or error out - is the error message going to
> >>> be meaningful or rather cryptic?
> >>
> >> As above, nothing will happen.  The usr/lib23 directory will (I guess)
> >> never occur in a package, so never be searched for files with an soname.
> >>
> > We might want to have a simple check in makepkg, to high-light those.
> > If PKGBUILD has "provides" to a non-existant file, we could error out IMHO.
>  >
> > This will catch both typos on the packaging side as well as buggy
> > upstream - say they dropped/renamed the library, or a particular
> > configure combination no longer builds one of the dozen+ DSOs.
> >
>
> I don't understand this suggestion. There would be no non-existent
> provide, as makepkg would not add one unless it finds one in the
> configured path.  This is a complete change from the current system
> where the name of the library needed to be in the PKGBUILD.  Now makepkg
> will automatically detect and add these values.
>
> And we can't distinguish between a package that has no libraries to be
> provided and a makepkg.conf with a typo pointing to the wrong directory.
>

My bad, I didn't fully read the series and made the wrong assumption.
Please ignore the above.

-Emil

From allan at archlinux.org  Tue Dec 14 13:31:59 2021
From: allan at archlinux.org (Allan McRae)
Date: Tue, 14 Dec 2021 23:31:59 +1000
Subject: [PATCH] Replace libdepends/libprovides
In-Reply-To: <1639485244.vbfeqrxlt0.remmy@hydrogen.kyriasis.com>
References: <20211212105440.1129363-1-allan@archlinux.org>
 <CAMQ-g0fiti_b38q_E+urzo9GyZ2BqCymjDDVJ=FYsJoVrU4wcg@mail.gmail.com>
 <dbcf8a41-6e38-99e0-099a-af5a11c31612@archlinux.org>
 <1639485244.vbfeqrxlt0.remmy@hydrogen.kyriasis.com>
Message-ID: <41099042-e2d7-4615-de6c-c2202a5bd326@archlinux.org>

On 14/12/21 22:39, Johannes L?thberg wrote:
> Excerpts from Allan McRae's message of December 14, 2021 13:10:
>> On 14/12/21 21:51, Jan Alexander Steffens (heftig) wrote:
>>> On Sun, Dec 12, 2021 at 11:54 AM Allan McRae <allan at archlinux.org 
>>> <mailto:allan at archlinux.org>> wrote:
>>>
>>> ??? This patch series replaces the old libdepends/libprovides system 
>>> into
>>> ??? something akin to that used by APK.? In short, makepkg.conf will 
>>> have
>>> ??? a variable like:
>>>
>>> ??? LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
>>>
>>>
>>> What about packages that install libraries into non-standard dirs and 
>>> then configure ld.so to look?
>>>
>>> On my system I currently have:
>>>
>>> /usr/lib/libfakeroot
>>> /usr/lib/opencollada
>>> /usr/lib/openmpi
>>> /usr/lib/perf
>>>
>>> Can this somehow be covered? I guess ignoring it wouldn't leave us 
>>> any worse off.
>>
>> Sure.? E.g. the fakeroot PKGBUILD can add:
>>
>> LIB_DIRS+=('lib:usr/lib/libfakeroot')
>>
>> and lib:libfakeroot-0.so will be added as a provide.
>>
> 
> With the currently proposed patch it should already be added even 
> without touching LIB_DIRS, since the `find` command used doesn't limit 
> the depth.? And adding it to LIB_DIRS would cause it to be added to 
> provides= twice, unless the list is filtered later on in makepkg.

Good point!  It will not be added twice, as the list of sonames is run 
through a "sort -u" before finally adding them to depends.

> They just won't be added to depends= automatically unless added to 
> LIB_DIRS.

Correct.

Allan



From foxboron at archlinux.org  Sun Dec 19 17:49:04 2021
From: foxboron at archlinux.org (Morten Linderud)
Date: Sun, 19 Dec 2021 18:49:04 +0100
Subject: [PATCH] makepkg: Implement pkgtype in .PKGINFO
Message-ID: <20211219174904.542634-1-foxboron@archlinux.org>

From: Morten Linderud <morten at linderud.pw>

This implements pkgtype into .PKGINFO. This is useful to ensure tools
parsing packages do not miss important context on the creation of the
package.

For instance discovering if a given .pkg.tar is a debug package, one
would have to do heuristics on the pkgdesc and "${pkgbase}-debug".
However both of these values are controlled by the packager.

Similarly, the heuristic for discovering split packages is if pkgbase
and pkgname differ, which can happen in any package as both values are
packager controlled.

This should ensure we don't need to rely on heuristics and instead
include the context of how the package was created.

Signed-off-by: Morten Linderud <morten at linderud.pw>
---
 scripts/makepkg.sh.in | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 3c7977db..9f5fd401 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -601,6 +601,7 @@ write_pkginfo() {
 
 	write_kv_pair "pkgname" "$pkgname"
 	write_kv_pair "pkgbase" "$pkgbase"
+	write_kv_pair "pkgtype" "$pkgtype"
 
 	local fullver=$(get_full_version)
 	write_kv_pair "pkgver" "$fullver"
@@ -681,6 +682,8 @@ list_package_files() {
 create_package() {
 	(( NOARCHIVE )) && return 0
 
+	pkgtype=${pkgtype:-pkg}
+
 	if [[ ! -d $pkgdir ]]; then
 		error "$(gettext "Missing %s directory.")" "\$pkgdir/"
 		plainerr "$(gettext "Aborting...")"
@@ -765,6 +768,7 @@ create_debug_package() {
 
 	pkgdesc="Detached debugging symbols for $pkgname"
 	pkgname=$pkgbase- at DEBUGSUFFIX@
+	pkgtype=debug
 
 	create_package
 }
@@ -775,6 +779,8 @@ create_srcpackage() {
 	local srclinks="$(mktemp -d "$startdir"/srclinks.XXXXXXXXX)"
 	mkdir "${srclinks}"/${pkgbase}
 
+	pkgtype=src
+
 	msg2 "$(gettext "Adding %s...")" "$BUILDSCRIPT"
 	ln -s "${BUILDFILE}" "${srclinks}/${pkgbase}/${BUILDSCRIPT}"
 
@@ -950,6 +956,7 @@ run_single_packaging() {
 
 run_split_packaging() {
 	local pkgname_backup=("${pkgname[@]}")
+	pkgtype=split
 	backup_package_variables
 	for pkgname in ${pkgname_backup[@]}; do
 		run_single_packaging $pkgname
-- 
2.34.1


From foxboron at archlinux.org  Sun Dec 19 17:58:25 2021
From: foxboron at archlinux.org (Morten Linderud)
Date: Sun, 19 Dec 2021 18:58:25 +0100
Subject: [PATCH] makepkg: Use pkgbase in pkgdesc for debug packages
Message-ID: <20211219175825.546399-1-foxboron@archlinux.org>

From: Morten Linderud <morten at linderud.pw>

When trying to identify debug packages among other packages we
discovered that it's pkgname used in pkgdesc. Since pkgname can
sometimes be an array when building debug packages for a split package,
this could potentially include a pkgname that might not make sense
depending on the order of the array.

This patch simply uses pkgbase as it seems more correct.

Signed-off-by: Morten Linderud <morten at linderud.pw>
---
 scripts/makepkg.sh.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 9f5fd401..27d3373d 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -766,7 +766,7 @@ create_debug_package() {
 		fi
 	done
 
-	pkgdesc="Detached debugging symbols for $pkgname"
+	pkgdesc="Detached debugging symbols for $pkgbase"
 	pkgname=$pkgbase- at DEBUGSUFFIX@
 	pkgtype=debug
 
-- 
2.34.1


From jeremy at merelinux.org  Wed Dec 22 14:18:44 2021
From: jeremy at merelinux.org (Jeremy Huntwork)
Date: Wed, 22 Dec 2021 09:18:44 -0500
Subject: Interest in other signature libs/tools?
Message-ID: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>

Hello,

I've been using pacman for a little while in Mere Linux
(https://github.com/jhuntwork/merelinux). In trying to keep things
simple, I sidestepped support for digital signatures for a while, but
I'm now at a point where I'd like to include it. However, I'd prefer
not to use gpgme and friends. I'd rather use a more modern and simpler
library. I've been looking at things like minisign and signify.
Recently I found https://github.com/vstakhov/asignify which snapped
into pacman pretty easily and is pretty much exactly what I'm looking
for.

At the moment I only have a pretty hacky patch to make it work, so
nothing that is ready to share here. But I wanted to gauge if there is
any interest in supporting different libraries/tools, or if I would
need to maintain my own patch downstream.

Thanks much for your good work and any feedback you may have.

JH

From allan at archlinux.org  Thu Dec 23 14:53:24 2021
From: allan at archlinux.org (Allan McRae)
Date: Fri, 24 Dec 2021 00:53:24 +1000
Subject: Interest in other signature libs/tools?
In-Reply-To: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
References: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
Message-ID: <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>

On 23/12/21 00:18, Jeremy Huntwork wrote:
> Hello,
> 
> I've been using pacman for a little while in Mere Linux
> (https://github.com/jhuntwork/merelinux). In trying to keep things
> simple, I sidestepped support for digital signatures for a while, but
> I'm now at a point where I'd like to include it. However, I'd prefer
> not to use gpgme and friends. I'd rather use a more modern and simpler
> library. I've been looking at things like minisign and signify.
> Recently I found https://github.com/vstakhov/asignify which snapped
> into pacman pretty easily and is pretty much exactly what I'm looking
> for.
> 
> At the moment I only have a pretty hacky patch to make it work, so
> nothing that is ready to share here. But I wanted to gauge if there is
> any interest in supporting different libraries/tools, or if I would
> need to maintain my own patch downstream.
> 
> Thanks much for your good work and any feedback you may have.

Going into this blind having not looked at the other signing 
libraries...  but if there is substantial benefits of moving to another 
library, we would likely consider it.  Assuming there is rough feature 
parity.

A skim of the asignify indicates you would need to trust every key that 
signs a package, and not use a web-of-trust approach?  In fact, I don't 
see a way to assign trust to specific keys.  I could be wrong here.

Allan

From jeremy at merelinux.org  Thu Dec 23 15:14:11 2021
From: jeremy at merelinux.org (Jeremy Huntwork)
Date: Thu, 23 Dec 2021 10:14:11 -0500
Subject: Interest in other signature libs/tools?
In-Reply-To: <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>
References: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
 <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>
Message-ID: <CANytiYzN4jMHF0_H1nZ42iaTWLUp6P4oBL3RL0v963ccTOfcSg@mail.gmail.com>

On Thu, Dec 23, 2021 at 9:53 AM Allan McRae <allan at archlinux.org> wrote:
> Going into this blind having not looked at the other signing
> libraries...  but if there is substantial benefits of moving to another
> library, we would likely consider it.  Assuming there is rough feature
> parity.
>
> A skim of the asignify indicates you would need to trust every key that
> signs a package, and not use a web-of-trust approach?  In fact, I don't
> see a way to assign trust to specific keys.  I could be wrong here.

Yes, I believe with libraries in the pattern of minisign,
signify/asignify there is no support for a web-of-trust. For me that
isn't a problem for reasons I'll outline in a moment, but I think if
Arch were to adopt any of those libraries as standard, that would
involve a pretty fundamental shift in how you package and release, no
doubt a much larger discussion. I'm saying this without a completely
clear picture of your package release process, so I may be wrong.

The reason I don't see it as being a problem for me is that my intent
is to release authoritative packages from one source, a CI/CD pipeline
that is triggered off of the main repository. Validation and trust of
humans that are allowed to push to that repository and trigger
official releases can be handled via other mechanisms. Community
repositories might have slightly different requirements, but my
expectation is that every repository used could have one official
public key.

Anyway, I'm not trying to sell you on that model or suggest that Arch
adopt it. Just wondering if pacman itself is interested in supporting
it as an alternative for projects like mine.

Thanks again!

JH

From jeremy at merelinux.org  Thu Dec 23 15:30:24 2021
From: jeremy at merelinux.org (Jeremy Huntwork)
Date: Thu, 23 Dec 2021 10:30:24 -0500
Subject: Interest in other signature libs/tools?
In-Reply-To: <CANytiYzN4jMHF0_H1nZ42iaTWLUp6P4oBL3RL0v963ccTOfcSg@mail.gmail.com>
References: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
 <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>
 <CANytiYzN4jMHF0_H1nZ42iaTWLUp6P4oBL3RL0v963ccTOfcSg@mail.gmail.com>
Message-ID: <CANytiYwXSR7-TRL6LLgrarrkm+9eehD1RZyCNQQ2K3E58hyLJg@mail.gmail.com>

On Thu, Dec 23, 2021 at 10:14 AM Jeremy Huntwork <jeremy at merelinux.org> wrote:
> The reason I don't see it as being a problem for me is that my intent
> is to release authoritative packages from one source, a CI/CD pipeline
> that is triggered off of the main repository. Validation and trust of
> humans that are allowed to push to that repository and trigger
> official releases can be handled via other mechanisms. Community
> repositories might have slightly different requirements, but my
> expectation is that every repository used could have one official
> public key.

I suppose if I did have a reason for supporting multiple keys, those
would all have to be shipped/installed together and then pacman could
loop through them until one of them validates the sig. asignify is
fast enough though because of its methods and algorithms used (blake2)
that I don't really see that as an issue either.

JH

From allan at archlinux.org  Fri Dec 24 04:34:45 2021
From: allan at archlinux.org (Allan McRae)
Date: Fri, 24 Dec 2021 14:34:45 +1000
Subject: Interest in other signature libs/tools?
In-Reply-To: <CANytiYwXSR7-TRL6LLgrarrkm+9eehD1RZyCNQQ2K3E58hyLJg@mail.gmail.com>
References: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
 <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>
 <CANytiYzN4jMHF0_H1nZ42iaTWLUp6P4oBL3RL0v963ccTOfcSg@mail.gmail.com>
 <CANytiYwXSR7-TRL6LLgrarrkm+9eehD1RZyCNQQ2K3E58hyLJg@mail.gmail.com>
Message-ID: <6280d1b7-4658-77ff-960f-f0166daf74c9@archlinux.org>

On 24/12/21 01:30, Jeremy Huntwork wrote:
> On Thu, Dec 23, 2021 at 10:14 AM Jeremy Huntwork <jeremy at merelinux.org> wrote:
>> The reason I don't see it as being a problem for me is that my intent
>> is to release authoritative packages from one source, a CI/CD pipeline
>> that is triggered off of the main repository. Validation and trust of
>> humans that are allowed to push to that repository and trigger
>> official releases can be handled via other mechanisms. Community
>> repositories might have slightly different requirements, but my
>> expectation is that every repository used could have one official
>> public key.
> 
> I suppose if I did have a reason for supporting multiple keys, those
> would all have to be shipped/installed together and then pacman could
> loop through them until one of them validates the sig. asignify is
> fast enough though because of its methods and algorithms used (blake2)
> that I don't really see that as an issue either.

I'm not a fan of the idea that if a user has a handful of non-distro 
repositories configured, that every package signature would need checked 
against multiple keys until one passed.  Is there no way of identifying 
the correct signing key from the signature file?

Allan


From allan at archlinux.org  Fri Dec 24 08:00:35 2021
From: allan at archlinux.org (Allan McRae)
Date: Fri, 24 Dec 2021 18:00:35 +1000
Subject: [PATCH] LTO: Add -flto to LDFLAGS for clang
Message-ID: <20211224080035.1203489-1-allan@archlinux.org>

GCC automatically detects when it is linking LTO objects, but clang does
not.  Add -flto to LDFLAGS to make this work for clang too.

Signed-off-by: Allan McRae <allan at archlinux.org>
---
 scripts/libmakepkg/buildenv/lto.sh.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/libmakepkg/buildenv/lto.sh.in b/scripts/libmakepkg/buildenv/lto.sh.in
index 1f1ca53f..c3bd0fa4 100644
--- a/scripts/libmakepkg/buildenv/lto.sh.in
+++ b/scripts/libmakepkg/buildenv/lto.sh.in
@@ -33,5 +33,6 @@ buildenv_lto() {
 	if check_option "lto" "y"; then
 		CFLAGS+=" -flto"
 		CXXFLAGS+=" -flto"
+		LDFLAGS+=" -flto"
 	fi
 }
-- 
2.34.1


From jeremy at merelinux.org  Sat Dec 25 13:53:57 2021
From: jeremy at merelinux.org (Jeremy Huntwork)
Date: Sat, 25 Dec 2021 08:53:57 -0500
Subject: Interest in other signature libs/tools?
In-Reply-To: <6280d1b7-4658-77ff-960f-f0166daf74c9@archlinux.org>
References: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
 <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>
 <CANytiYzN4jMHF0_H1nZ42iaTWLUp6P4oBL3RL0v963ccTOfcSg@mail.gmail.com>
 <CANytiYwXSR7-TRL6LLgrarrkm+9eehD1RZyCNQQ2K3E58hyLJg@mail.gmail.com>
 <6280d1b7-4658-77ff-960f-f0166daf74c9@archlinux.org>
Message-ID: <CANytiYwU8iXzMbOg2+h3-_eATgZGviphY+fBp+SPeB-nphiNvw@mail.gmail.com>

On Thu, Dec 23, 2021 at 11:34 PM Allan McRae <allan at archlinux.org> wrote:
>
> I'm not a fan of the idea that if a user has a handful of non-distro
> repositories configured, that every package signature would need checked
> against multiple keys until one passed.  Is there no way of identifying
> the correct signing key from the signature file?
>

Yeah, I believe there is. Here's the contents of a generated public key:

asignify-pubkey:1:mtG16Izr+xQ=:FlDRmIlYxCG0QAm7Jjmf/im62EBfg2nCpwzGPpkq+30=

And here's the contents of the sig file made using the corresponding
private key:

asignify-sig:1:mtG16Izr+xQ=:txEF3fQ/gaBAVCi8WpDICWn9i7gqgfJXp/viJDQeeETfbZTheIXHitmXv9Z+RQO9dYQDkJ6AMZt/xTU1/lWlDQ==
BLAKE2 (test.c) =
f8222a69bb9672b76ad7cc8776902a4b5bdde47b64040cd6febe798df3c7545a1f86e1ae94898f63fe94e3cabb91cda359be6b12edddcccd95ef5fd965349600

So it looks like third field on the first line is a fingerprint for the key.

JH

From jeremy at merelinux.org  Sun Dec 26 22:01:08 2021
From: jeremy at merelinux.org (jeremy at merelinux.org)
Date: Sun, 26 Dec 2021 17:01:08 -0500
Subject: Initial support for asignify signatures
Message-ID: <20211226220108.13797-1-jeremy@merelinux.org>

From: Jeremy Huntwork <jeremy at merelinux.org>

This is a proof of concept that shows how asignify can be used instead
of gpgme to validate packages signed with the asignify tool.

Signed-off-by: Jeremy Huntwork <jeremy at merelinux.org>
---
 lib/libalpm/alpm.c       |  2 +-
 lib/libalpm/be_package.c | 10 ++++++
 lib/libalpm/be_sync.c    |  2 +-
 lib/libalpm/handle.c     |  6 ++--
 lib/libalpm/signing.c    | 67 ++++++++++++++++++++++++++++++++++++++++
 lib/libalpm/signing.h    | 11 ++++---
 meson.build              | 11 ++++++-
 meson_options.txt        |  3 ++
 8 files changed, 101 insertions(+), 11 deletions(-)

diff --git a/lib/libalpm/alpm.c b/lib/libalpm/alpm.c
index 5b326ab0..d1261660 100644
--- a/lib/libalpm/alpm.c
+++ b/lib/libalpm/alpm.c
@@ -137,7 +137,7 @@ int SYMEXPORT alpm_capabilities(void)
 #ifdef HAVE_LIBCURL
 		| ALPM_CAPABILITY_DOWNLOADER
 #endif
-#ifdef HAVE_LIBGPGME
+#if defined(HAVE_LIBGPGME) || defined(HAVE_LIBASIGNIFY)
 		| ALPM_CAPABILITY_SIGNATURES
 #endif
 		| 0;
diff --git a/lib/libalpm/be_package.c b/lib/libalpm/be_package.c
index 5ca2865c..1b6887ce 100644
--- a/lib/libalpm/be_package.c
+++ b/lib/libalpm/be_package.c
@@ -342,12 +342,20 @@ int _alpm_pkg_validate_internal(alpm_handle_t *handle,
 			handle->pm_errno = ALPM_ERR_PKG_MISSING_SIG;
 			return -1;
 		}
+#ifdef HAVE_LIBGPGME
 		if(_alpm_check_pgp_helper(handle, pkgfile, sig,
 					level & ALPM_SIG_PACKAGE_OPTIONAL, level & ALPM_SIG_PACKAGE_MARGINAL_OK,
 					level & ALPM_SIG_PACKAGE_UNKNOWN_OK, sigdata)) {
 			handle->pm_errno = ALPM_ERR_PKG_INVALID_SIG;
 			return -1;
 		}
+#endif
+#ifdef HAVE_LIBASIGNIFY
+		if(_alpm_check_asignify_helper(handle, pkgfile, sigdata)) {
+			handle->pm_errno = ALPM_ERR_PKG_INVALID_SIG;
+			return -1;
+		}
+#endif
 		if(validation && has_sig) {
 			*validation |= ALPM_PKG_VALIDATION_SIGNATURE;
 		}
@@ -743,6 +751,7 @@ int SYMEXPORT alpm_pkg_load(alpm_handle_t *handle, const char *filename, int ful
 				return -1;
 			}
 
+#ifndef HAVE_LIBASIGNIFY
 			if(alpm_extract_keyid(handle, filename, sig, len, &keys) == 0) {
 				alpm_list_t *k;
 				for(k = keys; k; k = k->next) {
@@ -771,6 +780,7 @@ int SYMEXPORT alpm_pkg_load(alpm_handle_t *handle, const char *filename, int ful
 				free(sigpath);
 				return -1;
 			}
+#endif
 		}
 	}
 	free(sigpath);
diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c
index ede25985..81654902 100644
--- a/lib/libalpm/be_sync.c
+++ b/lib/libalpm/be_sync.c
@@ -697,7 +697,7 @@ alpm_db_t *_alpm_db_register_sync(alpm_handle_t *handle, const char *treename,
 
 	_alpm_log(handle, ALPM_LOG_DEBUG, "registering sync database '%s'\n", treename);
 
-#ifndef HAVE_LIBGPGME
+#if !defined(HAVE_LIBGPGME) || !defined(HAVE_LIBASIGNIFY)
 	if(level != 0 && level != ALPM_SIG_USE_DEFAULT) {
 		RET_ERR(handle, ALPM_ERR_MISSING_CAPABILITY_SIGNATURES, NULL);
 	}
diff --git a/lib/libalpm/handle.c b/lib/libalpm/handle.c
index 101d4a78..78c7d7bd 100644
--- a/lib/libalpm/handle.c
+++ b/lib/libalpm/handle.c
@@ -829,7 +829,7 @@ int SYMEXPORT alpm_option_set_default_siglevel(alpm_handle_t *handle,
 	if(level == ALPM_SIG_USE_DEFAULT) {
 		RET_ERR(handle, ALPM_ERR_WRONG_ARGS, -1);
 	}
-#ifdef HAVE_LIBGPGME
+#if defined(HAVE_LIBGPGME) || defined(HAVE_LIBASIGNIFY)
 	handle->siglevel = level;
 #else
 	if(level != 0) {
@@ -849,7 +849,7 @@ int SYMEXPORT alpm_option_set_local_file_siglevel(alpm_handle_t *handle,
 		int level)
 {
 	CHECK_HANDLE(handle, return -1);
-#ifdef HAVE_LIBGPGME
+#if defined(HAVE_LIBGPGME) || defined(HAVE_LIBASIGNIFY)
 	handle->localfilesiglevel = level;
 #else
 	if(level != 0 && level != ALPM_SIG_USE_DEFAULT) {
@@ -873,7 +873,7 @@ int SYMEXPORT alpm_option_set_remote_file_siglevel(alpm_handle_t *handle,
 		int level)
 {
 	CHECK_HANDLE(handle, return -1);
-#ifdef HAVE_LIBGPGME
+#if defined(HAVE_LIBGPGME) || defined(HAVE_LIBASIGNIFY)
 	handle->remotefilesiglevel = level;
 #else
 	if(level != 0 && level != ALPM_SIG_USE_DEFAULT) {
diff --git a/lib/libalpm/signing.c b/lib/libalpm/signing.c
index 66cc3923..cf778f9d 100644
--- a/lib/libalpm/signing.c
+++ b/lib/libalpm/signing.c
@@ -26,6 +26,12 @@
 #include <gpgme.h>
 #endif
 
+#ifdef HAVE_LIBASIGNIFY
+/* libasignify */
+#include <asignify.h>
+#include <dirent.h>
+#endif
+
 /* libalpm */
 #include "signing.h"
 #include "package.h"
@@ -810,6 +816,67 @@ char *_alpm_sigpath(alpm_handle_t *handle, const char *path)
 	return sigpath;
 }
 
+/**
+ * Helper for checking the asignify signature for the given file path.
+ * @param handle the context handle
+ * @param path the full path to a file
+ * @param sigdata a pointer to storage for signature results
+ * @return 0 on success, -1 on error (consult pm_errno or sigdata)
+ */
+int _alpm_check_asignify_helper(alpm_handle_t *handle, const char *path,
+		alpm_siglist_t **sigdata)
+{
+		int ret = 0;
+		struct dirent *entry;
+		struct stat statbuf;
+		const char *pubkeydir = "/etc/pacman.d/trustedkeys"; /* Add config for this */
+
+		char *sigpath = _alpm_sigpath(handle, path);
+		asignify_verify_t *vrf = asignify_verify_init();
+
+		DIR *pkd = opendir(pubkeydir);
+		if(pkd == NULL) {
+			_alpm_log(handle, ALPM_LOG_DEBUG, "cannot open directory: %s\n", pubkeydir);
+			return -1;
+		}
+
+		while((entry = readdir(pkd)) != NULL) {
+			char *fullpath = malloc(strlen(pubkeydir) + strlen(entry->d_name) + 2);
+			if (fullpath == NULL) {
+				_alpm_log(handle, ALPM_LOG_DEBUG, "malloc error\n");
+				return -1;
+			}
+			sprintf(fullpath, "%s/%s", pubkeydir, entry->d_name);
+			stat(fullpath, &statbuf);
+			if (S_ISREG(statbuf.st_mode)) {
+				if (!asignify_verify_load_pubkey(vrf, fullpath)) {
+					/* Don't return here because there may be multiple public keys to load. */
+					_alpm_log(handle, ALPM_LOG_DEBUG, "cannot load public key file: %s\n", fullpath);
+				}
+			}
+			free(fullpath);
+		}
+
+		if (!asignify_verify_load_signature(vrf, sigpath)) {
+			_alpm_log(handle, ALPM_LOG_DEBUG, "cannot load signature\n");
+			ret = -1;
+			goto asignify_cleanup;
+		}
+
+		if (!asignify_verify_file(vrf, path)) {
+			_alpm_log(handle, ALPM_LOG_DEBUG, "signature is not valid\n");
+			ret = -1;
+			goto asignify_cleanup;
+		}
+
+		_alpm_log(handle, ALPM_LOG_DEBUG, "signature is valid\n");
+
+asignify_cleanup:
+		free(sigpath);
+		asignify_verify_free(vrf);
+		return ret;
+}
+
 /**
  * Helper for checking the PGP signature for the given file path.
  * This wraps #_alpm_gpgme_checksig in a slightly friendlier manner to simplify
diff --git a/lib/libalpm/signing.h b/lib/libalpm/signing.h
index 112b2a1f..ce859373 100644
--- a/lib/libalpm/signing.h
+++ b/lib/libalpm/signing.h
@@ -23,13 +23,14 @@
 
 char *_alpm_sigpath(alpm_handle_t *handle, const char *path);
 int _alpm_gpgme_checksig(alpm_handle_t *handle, const char *path,
-		const char *base64_sig, alpm_siglist_t *result);
-
+						 const char *base64_sig, alpm_siglist_t *result);
+int _alpm_check_asignify_helper(alpm_handle_t *handle, const char *path,
+								alpm_siglist_t **sigdata);
 int _alpm_check_pgp_helper(alpm_handle_t *handle, const char *path,
-		const char *base64_sig, int optional, int marginal, int unknown,
-		alpm_siglist_t **sigdata);
+						   const char *base64_sig, int optional, int marginal, int unknown,
+						   alpm_siglist_t **sigdata);
 int _alpm_process_siglist(alpm_handle_t *handle, const char *identifier,
-		alpm_siglist_t *siglist, int optional, int marginal, int unknown);
+						  alpm_siglist_t *siglist, int optional, int marginal, int unknown);
 
 int _alpm_key_in_keychain(alpm_handle_t *handle, const char *fpr);
 int _alpm_key_import(alpm_handle_t *handle, const char *uid, const char *fpr);
diff --git a/meson.build b/meson.build
index 76b9d2aa..fc9a6f1c 100644
--- a/meson.build
+++ b/meson.build
@@ -105,6 +105,14 @@ gpgme = dependency('gpgme',
                    not_found_message : 'gpgme @0@ is needed for GPG signature support'.format(needed_gpgme_version))
 conf.set('HAVE_LIBGPGME', gpgme.found())
 
+needed_libasignify_version = '>=1.0'
+libasignify = dependency('libasignify',
+                   version : needed_libasignify_version,
+                   required : get_option('asignify'),
+                   static : get_option('buildstatic'),
+                   not_found_message : 'libasignify @0@ is needed for asignify signature support'.format(needed_libasignify_version))
+conf.set('HAVE_LIBASIGNIFY', libasignify.found())
+
 want_crypto = get_option('crypto')
 if want_crypto == 'openssl'
   libcrypto = dependency('libcrypto', static : get_option('buildstatic'),
@@ -305,7 +313,7 @@ libcommon = static_library(
   gnu_symbol_visibility : 'hidden',
   install : false)
 
-alpm_deps = [crypto_provider, libarchive, libcurl, libintl, gpgme]
+alpm_deps = [crypto_provider, libarchive, libasignify, libcurl, libintl, gpgme]
 
 libalpm_a = static_library(
   'alpm_objlib',
@@ -453,6 +461,7 @@ message('\n    '.join([
   '  i18n support             : @0@'.format(get_option('i18n')),
   '  Build docs               : @0@'.format(build_doc),
   '  debug build              : @0@'.format(get_option('buildtype') == 'debug'),
+  '  Use libasignify          : @0@'.format(conf.get('HAVE_LIBASIGNIFY')),
   '  Use libcurl              : @0@'.format(conf.get('HAVE_LIBCURL')),
   '  Use GPGME                : @0@'.format(conf.get('HAVE_LIBGPGME')),
   '  Use OpenSSL              : @0@'.format(conf.has('HAVE_LIBSSL') and
diff --git a/meson_options.txt b/meson_options.txt
index 4d8cc300..a254a5d4 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -48,6 +48,9 @@ option('crypto', type : 'combo', choices : ['openssl', 'nettle'],
 option('gpgme', type : 'feature', value : 'auto',
        description : 'use GPGME for PGP signature verification')
 
+option('asignify', type : 'feature', value : 'auto',
+       description : 'use asignify for signature verification')
+
 option('i18n', type : 'boolean', value : true,
        description : 'enable localization of pacman, libalpm and scripts')
 
-- 
2.34.1


From jeremy at merelinux.org  Sun Dec 26 22:18:52 2021
From: jeremy at merelinux.org (Jeremy Huntwork)
Date: Sun, 26 Dec 2021 17:18:52 -0500
Subject: Initial support for asignify signatures
In-Reply-To: <20211226220108.13797-1-jeremy@merelinux.org>
References: <20211226220108.13797-1-jeremy@merelinux.org>
Message-ID: <CANytiYzKJ-jyg1xsi2b=S15xzpwMTpy=j9NvepzU-9h54TE4fQ@mail.gmail.com>

On Sun, Dec 26, 2021 at 5:01 PM <jeremy at merelinux.org> wrote:
>
> From: Jeremy Huntwork <jeremy at merelinux.org>
>
> This is a proof of concept that shows how asignify can be used instead
> of gpgme to validate packages signed with the asignify tool.

Just want to reiterate that this is a proof of concept. There is one
hard-coded path in there for now, the location of the trusted public
keys. That at the very least will need to be updated to a
configuration option. I also noticed that there are one or two
auto-formatting changes here that I didn't intend to include. Anyway,
thanks for reviewing. Looking forward to the feedback.

JH

From bjorn.bidar at thaodan.de  Sun Dec 26 23:24:05 2021
From: bjorn.bidar at thaodan.de (Bjoern Bidar)
Date: Mon, 27 Dec 2021 01:24:05 +0200
Subject: Interest in other signature libs/tools?
In-Reply-To: <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>
References: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
 <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org>
Message-ID: <4647008.44XtV9DnNk@odin>

Am Donnerstag, 23. Dezember 2021, 16:53:24 EET schrieb Allan McRae:
> On 23/12/21 00:18, Jeremy Huntwork wrote:
> > Hello,
> > 
> > I've been using pacman for a little while in Mere Linux
> > (https://github.com/jhuntwork/merelinux). In trying to keep things
> > simple, I sidestepped support for digital signatures for a while, but
> > I'm now at a point where I'd like to include it. However, I'd prefer
> > not to use gpgme and friends. I'd rather use a more modern and simpler
> > library. I've been looking at things like minisign and signify.
> > Recently I found https://github.com/vstakhov/asignify which snapped
> > into pacman pretty easily and is pretty much exactly what I'm looking
> > for.
> > 
> > At the moment I only have a pretty hacky patch to make it work, so
> > nothing that is ready to share here. But I wanted to gauge if there is
> > any interest in supporting different libraries/tools, or if I would
> > need to maintain my own patch downstream.
> > 
> > Thanks much for your good work and any feedback you may have.
> 
> Going into this blind having not looked at the other signing
> libraries...  but if there is substantial benefits of moving to another
> library, we would likely consider it.  Assuming there is rough feature
> parity.
Or what are the problems with the existing solution, what should be changed?
For example if are problems interfacing  with gpgme e.g. compared mininsign?



From jeremy at merelinux.org  Mon Dec 27 14:14:23 2021
From: jeremy at merelinux.org (Jeremy Huntwork)
Date: Mon, 27 Dec 2021 09:14:23 -0500
Subject: Interest in other signature libs/tools?
In-Reply-To: <4647008.44XtV9DnNk@odin>
References: <CANytiYwzKUoHUxE3EUp1PQo9VQnbdm4KOH9VFy9jr9DOVxoF2A@mail.gmail.com>
 <e475abff-341e-e202-5b49-610c3eae08fa@archlinux.org> <4647008.44XtV9DnNk@odin>
Message-ID: <CANytiYzd17ynBTn0chBhsfkH37mN0JsxJqG_=u8EbSd2rtjMog@mail.gmail.com>

On Sun, Dec 26, 2021 at 6:24 PM Bjoern Bidar <bjorn.bidar at thaodan.de> wrote:
>
> Or what are the problems with the existing solution, what should be changed?
> For example if are problems interfacing  with gpgme e.g. compared mininsign?
>

To be very clear, I'll just state again that I'm not proposing that
Arch undertake a change, or that pacman should drop support for gpgme.
My motivation is as a downstream user of pacman, and for my needs, I
would like to use a simpler, and more modern signature solution.

gpgme pulls in a lot of extra libraries and complexity that isn't
required for just package signing. I think you can see the difference
in complexity too by comparing pacman's current code for key
verification with the sample code here:
https://github.com/vstakhov/asignify#libasignify-api Of course a real
world implementation would require a bit more, but I think it still
illustrates the point.

Beyond that, some have made arguments that PGP is just generally bad:
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html But even
without those arguments, the complexity alone makes it less than ideal
for my use cases.

Up to now, the design of my distro has been very light and simple. I
can create a base Docker image with pacman and busybox at about 5MB. I
have been compiling pacman statically, and if I add in gpgme, pacman's
size doubles (IIRC). Besides that, when I last tested, it still
required that the gpg executable itself (and its dependencies) be
present on the machine.

At this point, my plan is to use pacman with asignify. It would just
be much nicer if I didn't need to maintain my own patch/fork.

JH

From allan at archlinux.org  Wed Dec 29 08:49:22 2021
From: allan at archlinux.org (Allan McRae (@allan))
Date: Wed, 29 Dec 2021 08:49:22 +0000
Subject: [Git][pacman/pacman][master] 9 commits: Fix file permissions
Message-ID: <61cc211291209_16075b841425db@gitlab.archlinux.org.mail>



Allan McRae pushed to branch master at Pacman / Pacman


Commits:
37109600 by Allan McRae at 2021-12-12T14:34:53+10:00
Fix file permissions

- - - - -
26ee6ff6 by Allan McRae at 2021-12-24T17:59:32+10:00
LTO: Add -flto to LDFLAGS for clang

GCC automatically detects when it is linking LTO objects, but clang does
not.  Add -flto to LDFLAGS to make this work for clang too.

Signed-off-by: Allan McRae &lt;allan at archlinux.org&gt;

- - - - -
354a300c by Allan McRae at 2021-12-29T15:20:05+10:00
makepkg: remove libdepends and libprovides

This will be replaced by a better system

Signed-off-by: Allan McRae &lt;allan at archlinux.org&gt;

- - - - -
060ab4a2 by Allan McRae at 2021-12-29T15:20:05+10:00
libmakepkg: add framework for autodeps

Signed-off-by: Allan McRae &lt;allan at archlinux.org&gt;

- - - - -
b2342800 by Allan McRae at 2021-12-29T15:20:05+10:00
libmakepkg: automatically add library sonames to provides

When the option &quot;autodeps&quot; is enabled, makepkg will add provides
entries for libraries found in the directories specified in LIB_DIRS
in makepkg.conf.  The entries LIB_DIRS array have the format
&quot;prefix:directory&quot;.  For example, the entry &quot;lib:usr/lib&quot; will search
$pkgdir/usr/lib for library sonames and add &quot;lib:libfoo.so.1&quot; to the
provides array.

Signed-off-by: Allan McRae &lt;allan at archlinux.org&gt;

- - - - -
9b766bad by Allan McRae at 2021-12-29T15:20:05+10:00
libmakepkg: automatically add library dependencies

Add linked libraries to a packages dependency list. This is the partner
to automatically generated library provides, and thus depends take the
same format. To help with bootstrapping, library dependencies are only
added if the relevant provide exists.

Signed-off-by: Allan McRae &lt;allan at archlinux.org&gt;

- - - - -
3a112668 by morganamilo at 2021-12-29T15:49:35+10:00
pacman: improve backup printing

The current backup printing does not fit in with the rest of the info at
all. Change to be more consistant.

Old:

Backup Files    :
MODIFIED	/etc/pacman.conf
UNMODIFIED	/etc/makepkg.conf

New:

Backup Files    : /etc/pacman.conf [modified]
                  /etc/makepkg.conf [unmodified]

Signed-off-by: morganamilo &lt;morganamilo at archlinux.org&gt;
Signed-off-by: Allan McRae &lt;allan at archlinux.org&gt;

- - - - -
58c81fa2 by morganamilo at 2021-12-29T16:16:18+10:00
alpm: return -1 for error in find_dl_candidates

This is the error value generally used and the calling function
explicitly checks for -1, later causing the error to be missed
and the transaction to continue.

&gt; pacman -S xterm
warning: xterm-369-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Package (1)  Old Version  New Version  Net Change  Download Size

extra/xterm  369-1        369-1          0.00 MiB       0.42 MiB

Total Download Size:   0.42 MiB
Total Installed Size:  1.05 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n]
error: no servers configured for repository: extra
(1/1) checking keys in keyring                                                                 [--------------------------------------------------------] 100%
(1/1) checking package integrity                                                               [--------------------------------------------------------] 100%
error: failed to commit transaction (wrong or NULL argument passed)
Errors occurred, no packages were upgraded.

- - - - -
9f236547 by Oskar Roesler (bionade24) via pacman-dev at 2021-12-29T17:53:51+10:00
pacman: print additional error information to stderr

Prints extra information provided by file conflict or corrupt package messages
to stderr instead of stdout

Signed-off-by: Oskar Roesler (bionade24) &lt;o.roesler at oscloud.info&gt;
Signed-off-by: Allan McRae &lt;allan at archlinux.org&gt;

- - - - -


15 changed files:

- doc/PKGBUILD.5.asciidoc
- doc/makepkg.conf.5.asciidoc
- etc/makepkg.conf.in
- lib/libalpm/sync.c
- + scripts/libmakepkg/autodep.sh.in
- + scripts/libmakepkg/autodep/library_depends.sh.in
- + scripts/libmakepkg/autodep/library_provides.sh.in
- + scripts/libmakepkg/autodep/meson.build
- scripts/libmakepkg/buildenv/lto.sh.in
- scripts/libmakepkg/lint_config.sh.in
- scripts/libmakepkg/meson.build
- scripts/makepkg.sh.in
- src/pacman/package.c
- src/pacman/package.h
- src/pacman/sync.c


View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/d21fb58da30a2bed405f9662e5ded3c31dddeccd...9f23654722b849b76ec15f6513ecb9265540ea59

-- 
View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/d21fb58da30a2bed405f9662e5ded3c31dddeccd...9f23654722b849b76ec15f6513ecb9265540ea59
You're receiving this email because of your account on gitlab.archlinux.org.