Re: [pacman-dev] [PATCH 2/3] libmakepkg: implement extendable source protocols

[Allan McRae]

On 29/05/18 14:30, Eli Schwartz wrote:
> Lookup the existence of matching functions for each protocol, and
> fallback on the generic file handler. New source protocols can then be
> added via thirdparty libmakepkg drop-ins without requiring modifications
> to source.sh
> 
> Fixes FS#49076
> 
> Signed-off-by: Eli Schwartz 
> ---
>  scripts/libmakepkg/source.sh.in | 46 +
>  1 file changed, 12 insertions(+), 34 deletions(-)
> 
> diff --git a/scripts/libmakepkg/source.sh.in b/scripts/libmakepkg/source.sh.in
> index 198efd5e..c07ce76d 100644
> --- a/scripts/libmakepkg/source.sh.in
> +++ b/scripts/libmakepkg/source.sh.in
> @@ -60,25 +60,15 @@ download_sources() {
>  
>   local proto=$(get_protocol "$netfile")
>   case "$proto" in
> - local)
> - download_local "$netfile"
> - ;;
> - bzr)
> - (( get_vcs )) && download_bzr "$netfile"
> - ;;
> - git)
> - (( get_vcs )) && download_git "$netfile"
> - ;;
> - hg)
> - (( get_vcs )) && download_hg "$netfile"
> - ;;
> - svn)
> - (( get_vcs )) && download_svn "$netfile"
> - ;;
> - *)
> - download_file "$netfile"
> + bzr|git|hg|svn)
> + (( get_vcs )) || continue
>   ;;

Should this be moved into the download_$proto functions?  I'd guess most
of the dropins would be for other vcs systems, and this is not extendable.

>   esac
> + if declare -f download_$proto > /dev/null; then
> + download_$proto "$netfile"
> + else
> + download_file "$netfile"
> + fi
>  
>   popd &>/dev/null
>   done
> @@ -92,22 +82,10 @@ extract_sources() {
>   for netfile in "${all_sources[@]}"; do
>   local file=$(get_filename "$netfile")
>   local proto=$(get_protocol "$netfile")
> - case "$proto" in
> - bzr)
> - extract_bzr "$netfile"
> - ;;
> - git)
> - extract_git "$netfile"
> - ;;
> - hg)
> - extract_hg "$netfile"
> - ;;
> - svn)
> - extract_svn "$netfile"
> - ;;
> - *)
> - extract_file "$file"
> - ;;
> - esac
> + if declare -f extract_$proto > /dev/null; then
> + extract_$proto "$netfile"
> + else
> + extract_file "$file"
> + fi
>   done
>  }
> 

Re: [pacman-dev] [PATCH] pacman-key: just accept one file to verify, and enforce detached sigs

[Allan McRae]

On 30/05/18 03:00, Eli Schwartz wrote:
> Simply pass options on to gpg the same way gpg uses them -- no looping
> through and checking lots of signatures.
> 
> This prevents a situation where the signature file to be verified is
> manipulated to contain a complete signature which is valid, but not a
> detached signature for the file you are actually trying to verify.
> 
> gpg does not offer an option to verify many files at once by naming each
> signature/file pair, and there's no reason for us to do so either, since
> it would be quite tiresome to do so.
> 
> Signed-off-by: Eli Schwartz 
> ---
>  scripts/pacman-key.sh.in | 25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
> index 0f1630a9..0573e92f 100644
> --- a/scripts/pacman-key.sh.in
> +++ b/scripts/pacman-key.sh.in
> @@ -486,18 +486,19 @@ refresh_keys() {
>  }
>  
>  verify_sig() {
> - local ret=0
> - for sig; do
> - msg "Checking %s..." "$sig"
> - if grep -q 'BEGIN PGP SIGNATURE' "$sig"; then
> - error "$(gettext "Cannot use armored signatures for 
> packages: %s")" "$sig"
> - return 1
> - fi
> - if ! "${GPG_PACMAN[@]}" --status-fd 1 --verify "$sig" | grep 
> -qE '^\[GNUPG:\] TRUST_(FULLY|ULTIMATE).*$'; then
> - error "$(gettext "The signature identified by %s could 
> not be verified.")" "$sig"
> - ret=1
> - fi
> - done
> + local ret=0 sig=$1 file=$2
> + if [[ -z $file ]]; then
> + file=${sig%.*}
> + fi

Opinions on if we should we do this?  All pacman's infrastructure
assumes detached signatures, but this is a difference from how gpg does
things when only one argument is given.


> + msg "Checking %s..." "$sig"
> + if grep -q 'BEGIN PGP SIGNATURE' "$sig"; then
> + error "$(gettext "Cannot use armored signatures for packages: 
> %s")" "$sig"
> + exit 1
> + fi
> + if ! "${GPG_PACMAN[@]}" --status-fd 1 --verify "$sig" "$file" | grep 
> -qE '^\[GNUPG:\] TRUST_(FULLY|ULTIMATE).*$'; then
> + error "$(gettext "The signature identified by %s could not be 
> verified.")" "$sig"
> + ret=1
> + fi
>   exit $ret
>  }
>  
> 

Re: [pacman-dev] [PATCH] Add lz4 compression support to makepkg

[Allan McRae]

On 31/05/18 23:31, Alex Butler wrote:
> Adds opt-in lz4 compression of *pkg.tar files with makepkg.
> This is nice to have as an option for very fast compression
> and is already installed with libarchive.
> 
> Signed-off-by: Alex Butler
> ---

This patch is fine in principle.  But I think we need to figure out what
to do with all the COMPRESS* options.  This will make seven of them and
we have a request for another compression method too.  There has to be a
more efficient way of overriding the range of compression options.

>  doc/makepkg.conf.5.asciidoc| 3 ++-
>  etc/makepkg.conf.in| 1 +
>  scripts/libmakepkg/util/compress.sh.in | 1 +
>  3 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/makepkg.conf.5.asciidoc b/doc/makepkg.conf.5.asciidoc
> index 3b596a91..7fd75a1d 100644
> --- a/doc/makepkg.conf.5.asciidoc
> +++ b/doc/makepkg.conf.5.asciidoc
> @@ -251,6 +251,7 @@ Options
>  **COMPRESSXZ=**"(xz -c -z -)"::
>  **COMPRESSLZO**"(lzop -q)"::
>  **COMPRESSLRZ=**"(lrzip -q)"::
> +**COMPRESSLZ4=**"(lz4 -q)"::
>  **COMPRESSZ=**"(compress -c -f)"::
>   Sets the command and options used when compressing compiled or source
>   packages in the named format.
> @@ -258,7 +259,7 @@ Options
>  **PKGEXT=**".pkg.tar.gz", **SRCEXT=**".src.tar.gz"::
>   Sets the compression used when making compiled or source packages.
>   Valid suffixes are `.tar`, `.tar.gz`, `.tar.bz2`, `.tar.xz`,
> - `.tar.lzo`, `.tar.lrz`, and `.tar.Z`.
> + `.tar.lzo`, `.tar.lrz`, `.tar.lz4`, and `.tar.Z`.
>   Do not touch these unless you know what you are doing.
>  
>  
> diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in
> index 1cf79664..01f8df2c 100644
> --- a/etc/makepkg.conf.in
> +++ b/etc/makepkg.conf.in
> @@ -133,6 +133,7 @@ COMPRESSXZ=(xz -c -z -)
>  COMPRESSLRZ=(lrzip -q)
>  COMPRESSLZO=(lzop -q)
>  COMPRESSZ=(compress -c -f)
> +COMPRESSLZ4=(lz4 -q)
>  
>  #
>  # EXTENSION DEFAULTS
> diff --git a/scripts/libmakepkg/util/compress.sh.in 
> b/scripts/libmakepkg/util/compress.sh.in
> index 3a332817..4d8cd46a 100644
> --- a/scripts/libmakepkg/util/compress.sh.in
> +++ b/scripts/libmakepkg/util/compress.sh.in
> @@ -40,6 +40,7 @@ compress_as() {
>   *tar.lrz) ${COMPRESSLRZ[@]:-lrzip -q} ;;
>   *tar.lzo) ${COMPRESSLZO[@]:-lzop -q} ;;
>   *tar.Z)   ${COMPRESSZ[@]:-compress -c -f} ;;
> + *tar.lz4) ${COMPRESSLZ4[@]:-lz4 -q} ;;
>   *tar) cat ;;
>   *) warning "$(gettext "'%s' is not a valid archive 
> extension.")" \
>   "$ext"; cat ;;
> 

[pacman-dev] [PATCH] PKGBUILD.5: document restriction on pkgrel

[Allan McRae]

The format of pkgrel was much more retrictive than described in the
man page. Update the documentation to reflect this.

Signed-off-by: Allan McRae 
---

Is this explanation clear?  We also need to update the error message from
lint_pkgrel to be more accurate.

 doc/PKGBUILD.5.asciidoc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc
index ac26f3fe..b7e07165 100644
--- a/doc/PKGBUILD.5.asciidoc
+++ b/doc/PKGBUILD.5.asciidoc
@@ -56,11 +56,13 @@ new `pkgver`.  This is most useful when used with sources 
from version control
 systems (see below).
 
 *pkgrel*::
-   This is the release number specific to the Arch Linux release. This
+   This is the release number specific to the distribution. This
allows package maintainers to make updates to the package's configure
flags, for example. This is typically set to '1' for each new upstream
software release and incremented for intermediate PKGBUILD updates. The
-   variable is not allowed to contain hyphens.
+   variable is a postive integer, with an optional subrelease level
+   specified by adding another postive integer separated by a period
+   (i.e. in the form x.y).
 
 *epoch*::
Used to force the package to be seen as newer than any previous versions
-- 
2.17.0

Re: [pacman-dev] [PATCH] makepkg: fix regression which broke split pkgbase-debug package metadata

[Allan McRae]

On 01/06/18 10:31, Eli Schwartz wrote:
> In commit 9e52a36794552b77ecf26f7f34b226d096978f1e the split package
> metadata backup/restore was refactored to use declare, which actually
> declares variables in a local scope when in a function. This did not
> play nicely with debug packages, which unset most metadata variables,
> thereby reverting to the global scope rather than resulting in unset
> metadata.
> 
> Fix by explicitly marking the variables as global.
> 

This requires bash-4.2.   We released pacman-5.1 with bash-4.1 as the
minimum required version.

This might work:

printf '%s\n' "printf -v \"$var\" \"${!var}\""


> Signed-off-by: Eli Schwartz 
> ---
>  scripts/makepkg.sh.in | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index 21737af8..fe3891ce 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -1124,7 +1124,12 @@ check_build_status() {
>  backup_package_variables() {
>   local var
>   for var in ${splitpkg_overrides[@]}; do
> - declare -p $var 2>/dev/null || printf '%s\n'  "unset $var"
> + if [[ ${!var} ]]; then
> + printf '%s\n' "declare -g $var"
> + declare -p $var
> + else
> + printf '%s\n'  "unset $var"
> + fi
>   done
>  }
>  
> 

Re: [pacman-dev] [PATCH] pacman.conf: Fixup the XferCommand example for curl

[Allan McRae]

On 04/06/18 06:01, Luke Shumaker wrote:
> From: Luke Shumaker 
> 
>  1. Without `-L`, curl doesn't follow redirects.  This is different than
> both the default behavior of pacman, and from the wget example.  So add
> `-L`.
> 
>  2. It uses `-C -` to supposedly allow resuming partial downloads; but that
> doesn't work if we use `> %o` to direct the output to the file.
> Instead, use `-o %o` so that `-C -` actually works.
> 
> Signed-off-by: Luke Shumaker 
> ---


OK.

Allan

Re: [pacman-dev] [PATCH 02/10] makepkg: Simplify SPLITPKG check

[Allan McRae]

On 01/06/18 07:01, Eli Schwartz wrote:
> On 05/31/2018 12:24 PM, Jan Alexander Steffens (heftig) wrote:
>> This causes package_$pkgname() to be preferred over package() in the
>> non-split case, but the behavior if both functions exist was
>> undocumented anyway.
> 
> We don't document the behavior of arbitrary user-defined functions.
> package_$pkgname() is only defined as having meaning in the context of
> the PACKAGE SPLITTING section of the documentation.
> 
> IMHO this is us documenting that package() is the only correct function
> unless ${#pkgname[@]} > 1.
> 
> I think it is far more intuitive to behave that way, and I'd actually be
> willing to refuse to use package_$pkgname even if it is the only one...
> 

We discussed on IRC to abort if both are present as undefined behavoiur.

Allan

Re: [pacman-dev] [PATCH] makepkg: Treat pkgrel more similarly to pkgver

[Allan McRae]

On 04/06/18 06:01, Luke Shumaker wrote:
> From: Luke Shumaker 
> 
> This is perfectly fine with libalpm; it was only makepkg that was more
> strict with pkgrel than pkgver.
> 
> Further, the former error message about invalid pkgrel formats claimed that
> pkgrel was a "decimal", which would mean that `1.1 == 1.10`.  This is not
> the case; alpm parses pkgrel as a version, not as a decimal.
> 
> Signed-off-by: Luke Shumaker 
> ---

I am still very much against going beyond x.y for pkgrel.   In fact, I
only begrudgingly accept the need for .y in there.

A

[pacman-dev] [PATCH] makepkg: fix erroneous $BUILDDIR when $startdir is not an absolute path

[Eli Schwartz]

When comparing the $BUILDDIR to the $startdir, we used string equality
instead of testing whether they are the same location, and ended up
appending $pkgbase even though there's no reason to use it here.

In some cases, this could result in makepkg erroring when trying to
create $srcdir/$pkgdir, if a file with the same name as the $pkgbase
exists. This is expected behavior if a file "src" or "pkg" exists, but
decidedly less so for $pkgbase.

This could be fixed either by setting $startdir to an absolute path, or
by ensuring the test checks this directly; I've chosen to do both, since
the test should really be correctly checking the thing it actually cares
about, but since we ensure absolute paths are used everywhere else, this
might bite us elsewhere someday. It's also more consistent.

Fixes FS#58865

Signed-off-by: Eli Schwartz 
---
 scripts/makepkg.sh.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 2ed8561f..efa21e7f 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -44,7 +44,7 @@ unset GREP_OPTIONS
 declare -r makepkg_version='@PACKAGE_VERSION@'
 declare -r confdir='@sysconfdir@'
 declare -r BUILDSCRIPT='@BUILDSCRIPT@'
-declare -r startdir="$PWD"
+declare -r startdir="$(pwd -P)"
 
 LIBRARY=${LIBRARY:-'@libmakepkgdir@'}
 
@@ -1458,7 +1458,7 @@ fi
 
 basever=$(get_full_version)
 
-if [[ $BUILDDIR = "$startdir" ]]; then
+if [[ $BUILDDIR -ef "$startdir" ]]; then
srcdir="$BUILDDIR/src"
pkgdirbase="$BUILDDIR/pkg"
 else
-- 
2.17.1

Re: [pacman-dev] [PATCH] Strip leading "/" from arguments to --overwrite

[Allan McRae]

On 02/06/18 09:01, Joey Pabalinas wrote:
> On Fri, Jun 01, 2018 at 06:56:13PM -0400, Andrew Gregory wrote:
>> Sort of.  The current --root option is a confusing mess that nobody
>> actually understands, so it will go away at some point.  The
>> underlying libalpm rootdir setting isn't going anywhere though, and,
>> in the future, will be configured with a new --rootdir option.
> 
> Well looking at the code it actually isn't as complicated as I thought it
> would be.
> 
> How about something like this:
> 
>> case OP_OVERWRITE_FILES:
>>  {
>>  char *i, *root = config->rootdir, *save = NULL;
>>  for(i = strtok_r(optarg, ",", ); i; i = strtok_r(NULL, 
>> ",", )) {
>>  /* strip rootdir if applicable */
>>  if (root && !memcmp(i, root, strlen(root)))
>>  i += strlen(root);
>>  /* strip remaining leading "/" before adding to option 
>> list */
>>  i += strspn(i, "/");
>>  config->overwrite_files = 
>> alpm_list_add(config->overwrite_files, strdup(i));
>>  }
>>  }
> 
> which would strip the rootdir and then the leading "/". Although I am not
> 100% certain config->rootdir would be NULL if no argument is passed; could
> you confirm that part?
> 

This will not work - we need to handle this after the config file is
read as the root dir may be set there.

A

Re: [pacman-dev] [PATCH 09/10] makepkg: Clear ERR trap before trying to restore it

[Jan Alexander Steffens]

On Mon, Jun 4, 2018 at 1:05 PM Allan McRae  wrote:

> On 04/06/18 18:47, Jan Alexander Steffens wrote:
> > The ERR trap is not inherited by functions unless the "errtrace" option
> > is set. So in the current situation, makepkg's internal functions are
> > supposed to do manual error checking. Bad returns from function calls at
> > the top level will trigger the trap, though.
> >
>
> Is there any point to the restoretrap variable then?


Probably not. I don't think we nest run_function_safe calls. Then again, it
doesn't hurt, either.

Re: [pacman-dev] [PATCH 09/10] makepkg: Clear ERR trap before trying to restore it

[Allan McRae]

On 04/06/18 18:47, Jan Alexander Steffens wrote:
> The ERR trap is not inherited by functions unless the "errtrace" option
> is set. So in the current situation, makepkg's internal functions are
> supposed to do manual error checking. Bad returns from function calls at
> the top level will trigger the trap, though.
> 

Is there any point to the restoretrap variable then?

A

> On Mon, Jun 4, 2018 at 9:59 AM Allan McRae  > wrote:
> 
> On 01/06/18 02:24, Jan Alexander Steffens (heftig) wrote:
> > $restoretrap is empty if the trap was not set. This caused the trap
> > handler to remain and override later exit codes.
> 
> How is this ever unset? We set the error trap early in makepkg:
> 
> trap 'trap_exit USR1 "$(gettext "An unknown error has occurred.
> Exiting...")"' ERR
> 
> 
> > ---
> >  scripts/makepkg.sh.in  | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/scripts/makepkg.sh.in 
> b/scripts/makepkg.sh.in 
> > index ed0ceaec..3a3f4c30 100644
> > --- a/scripts/makepkg.sh.in 
> > +++ b/scripts/makepkg.sh.in 
> > @@ -432,6 +432,7 @@ run_function_safe() {
> > 
> >       run_function "$1"
> > 
> > +     trap - ERR
> >       eval "$restoretrap"
> >       eval "$restoreset"
> >       eval "$restoreshopt"
> >
> 

Re: [pacman-dev] [PATCH] Add lz4 compression support to makepkg

[Alex Butler]

On 4 June 2018 at 08:48, Allan McRae  wrote:

> On 31/05/18 23:31, Alex Butler wrote:
> > Adds opt-in lz4 compression of *pkg.tar files with makepkg.
> > This is nice to have as an option for very fast compression
> > and is already installed with libarchive.
> >
> > Signed-off-by: Alex Butler
> > ---
>
> This patch is fine in principle.  But I think we need to figure out what
> to do with all the COMPRESS* options.  This will make seven of them and
> we have a request for another compression method too.  There has to be a
> more efficient way of overriding the range of compression options.
>
>
Perhaps. Though adding a new libarchive-supported compression option
currently costs 1 line of code, 1 line of conf & 1 line of docs. I'd say
that
was pretty good.

I also don't see that this patch particularly complicates any future
efforts
to improve the compression handling.

Re: [pacman-dev] [PATCH 09/10] makepkg: Clear ERR trap before trying to restore it

[Jan Alexander Steffens]

The ERR trap is not inherited by functions unless the "errtrace" option is
set. So in the current situation, makepkg's internal functions are supposed
to do manual error checking. Bad returns from function calls at the top
level will trigger the trap, though.

On Mon, Jun 4, 2018 at 9:59 AM Allan McRae  wrote:

> On 01/06/18 02:24, Jan Alexander Steffens (heftig) wrote:
> > $restoretrap is empty if the trap was not set. This caused the trap
> > handler to remain and override later exit codes.
>
> How is this ever unset? We set the error trap early in makepkg:
>
> trap 'trap_exit USR1 "$(gettext "An unknown error has occurred.
> Exiting...")"' ERR
>
>
> > ---
> >  scripts/makepkg.sh.in | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> > index ed0ceaec..3a3f4c30 100644
> > --- a/scripts/makepkg.sh.in
> > +++ b/scripts/makepkg.sh.in
> > @@ -432,6 +432,7 @@ run_function_safe() {
> >
> >   run_function "$1"
> >
> > + trap - ERR
> >   eval "$restoretrap"
> >   eval "$restoreset"
> >   eval "$restoreshopt"
> >
>

Re: [pacman-dev] [PATCH 2/3] libmakepkg: implement extendable source protocols

[Eli Schwartz]

On 06/04/2018 02:56 AM, Allan McRae wrote:
>> +bzr|git|hg|svn)
>> +(( get_vcs )) || continue
>>  ;;
> 
> Should this be moved into the download_$proto functions?  I'd guess most
> of the dropins would be for other vcs systems, and this is not extendable.
Hmm.

Well, other VCS systems could implement private routines for "return 0"
early on this, but it isn't strictly necessary for here. It's mildly
more verbose, but OTOH it also makes things slightly more obvious. I
guess just for the sake of clarity it should do as you suggested...

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [pacman-dev] [PATCH 09/10] makepkg: Clear ERR trap before trying to restore it

[Allan McRae]

On 01/06/18 02:24, Jan Alexander Steffens (heftig) wrote:
> $restoretrap is empty if the trap was not set. This caused the trap
> handler to remain and override later exit codes.

How is this ever unset? We set the error trap early in makepkg:

trap 'trap_exit USR1 "$(gettext "An unknown error has occurred.
Exiting...")"' ERR


> ---
>  scripts/makepkg.sh.in | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> index ed0ceaec..3a3f4c30 100644
> --- a/scripts/makepkg.sh.in
> +++ b/scripts/makepkg.sh.in
> @@ -432,6 +432,7 @@ run_function_safe() {
>  
>   run_function "$1"
>  
> + trap - ERR
>   eval "$restoretrap"
>   eval "$restoreset"
>   eval "$restoreshopt"
> 

Re: [pacman-dev] pacman user+group support without mtree

[Andrew Gregory]

On 06/04/18 at 05:01pm, Eli Schwartz wrote:
> On 06/04/2018 04:55 PM, pacman-dev via pacman-dev wrote:
> > 
> > Hello Pacman Dev, The basic question first, is there a way to create
> > a tarball with .PKGINFO and use that tarball as a pacman package to
> > install files with particular permissions without also adding a
> > .MTREE file to that tarball?
> > 
> > More context, currently we install files into our servers using a
> > bash script.  It pops open a tarball, keeping the users, groups,
> > permissions, times for the files in the tarball, then it copies each
> > file to the filesystem according to their location in the tarball.
> > It works great for a cheap slightly better then POC solution.  That
> > tarball and a pacman pkg file are vary similar in that those are both
> > tar files, with the files listed according to their desired location
> > on the filesystem.So my idea was that it would be relatively easy
> > for me to add the appropriate .PKGINFO into the tarball and switch
> > from using my bash script to using pacman itself.  This all worked
> > great, except for users.  In this case the file was created, in the
> > right place, with the right permissions but the wrong user and group.
> 
> I'd suggest you have two choices to proceed from here:
> - use makepkg to repackage your tarball
> - generate the .MTREE which pacman expects
> 
> The .MTREE is simple to make, this is where makepkg generates it:
> https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in?h=v5.1.0#n763
> 
> As you can see, it's really just bsdtar --format=mtree with a couple
> other options.

pacman extracts the file with whatever uid and gid it has in the
tarball.  The mtree file is completely irrelevant.

[pacman-dev] pacman user+group support without mtree

[pacman-dev via pacman-dev]

Hello Pacman Dev,
The basic question first, is there a way to create a tarball with .PKGINFO and 
use that tarball as a pacman package to install files with particular 
permissions without also adding a .MTREE file to that tarball?

More context, currently we install files into our servers using a bash script.  
It pops open a tarball, keeping the users, groups, permissions, times for the 
files in the tarball, then it copies each file to the filesystem according to 
their location in the tarball.  It works great for a cheap slightly better then 
POC solution.  That tarball and a pacman pkg file are vary similar in that 
those are both tar files, with the files listed according to their desired 
location on the filesystem.So my idea was that it would be relatively easy 
for me to add the appropriate .PKGINFO into the tarball and switch from using 
my bash script to using pacman itself.  This all worked great, except for 
users.  In this case the file was created, in the right place, with the right 
permissions but the wrong user and group.  

$ tar -tvf vienna-os-scaffold-0.0.0-any.pkg.tar.xz | grep sbin/vienna
-r-x-- vienna/nogroup   533 2017-12-04 13:18 
usr/local/sbin/vienna
...
$ sudo pacman  --noconfirm -U vienna-os-scaffold-0.0.0-any.pkg.tar.xz 
warning: no 'XferCommand' configured
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) vienna-os-scaffold-0.0.0-0


:: Proceed with installation? [Y/n] 
(1/1) checking package integrity


[#]
 100%
(1/1) loading package files 


[#]
 100%
(1/1) checking for file conflicts   


[#]
 100%
(1/1) checking available disk space 


[#]
 100%
:: Processing package changes...
(1/1) installing vienna-os-scaffold 
...
$ ls -l /usr/local/sbin/vienna
-r-x-- 1 501 dialout 533 Dec  4 13:18 /usr/local/sbin/vienna

As the above shell script snippets demonstrate, the file usr/local/sbin/vienna 
is owned by "vienna" in the tarball, and assigned to group "nogroup".  It also 
is only readable and execute by the user.   When deployed by pacman it retains 
the permission and is installed at /usr/local/sbin/vienna.  Which is correct, 
but it is owned by dialout and 553?  This is not correct.  If I want the file 
to be installed with user=vienna and group=nogroup, do I need to create a 
.mtree file and add that to the package as well or is there some other way I 
can get pacman to look at the user and group of the file inside the tarball?

Michael Power

Re: [pacman-dev] pacman user+group support without mtree

[Eli Schwartz]

On 06/04/2018 04:55 PM, pacman-dev via pacman-dev wrote:
> 
> Hello Pacman Dev, The basic question first, is there a way to create
> a tarball with .PKGINFO and use that tarball as a pacman package to
> install files with particular permissions without also adding a
> .MTREE file to that tarball?
> 
> More context, currently we install files into our servers using a
> bash script.  It pops open a tarball, keeping the users, groups,
> permissions, times for the files in the tarball, then it copies each
> file to the filesystem according to their location in the tarball.
> It works great for a cheap slightly better then POC solution.  That
> tarball and a pacman pkg file are vary similar in that those are both
> tar files, with the files listed according to their desired location
> on the filesystem.So my idea was that it would be relatively easy
> for me to add the appropriate .PKGINFO into the tarball and switch
> from using my bash script to using pacman itself.  This all worked
> great, except for users.  In this case the file was created, in the
> right place, with the right permissions but the wrong user and group.

I'd suggest you have two choices to proceed from here:
- use makepkg to repackage your tarball
- generate the .MTREE which pacman expects

The .MTREE is simple to make, this is where makepkg generates it:
https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in?h=v5.1.0#n763

As you can see, it's really just bsdtar --format=mtree with a couple
other options.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [pacman-dev] pacman-dev Digest, Vol 153, Issue 9

[pacman-dev via pacman-dev]

#]
 >  100% 
 > :: Processing package changes... 
 > (1/1) installing vienna-os-scaffold  
 > ... 
 > $ ls -l /usr/local/sbin/vienna 
 > -r-x-- 1 501 dialout 533 Dec  4 13:18 /usr/local/sbin/vienna 
 >  
 > As the above shell script snippets demonstrate, the file 
 > usr/local/sbin/vienna is owned by "vienna" in the tarball, and assigned to 
 > group "nogroup".  It also is only readable and execute by the user.   When 
 > deployed by pacman it retains the permission and is installed at 
 > /usr/local/sbin/vienna.  Which is correct, but it is owned by dialout and 
 > 553?  This is not correct.  If I want the file to be installed with 
 > user=vienna and group=nogroup, do I need to create a .mtree file and add 
 > that to the package as well or is there some other way I can get pacman to 
 > look at the user and group of the file inside the tarball? 
 >  
 > Michael Power 
 >  
 >  
 > -- 
 >  
 > Message: 5 
 > Date: Mon, 4 Jun 2018 17:01:22 -0400 
 > From: Eli Schwartz  
 > To: pacman-dev@archlinux.org 
 > Subject: Re: [pacman-dev] pacman user+group support without mtree 
 > Message-ID: <427232e1-ae1f-fafd-7e82-6c34fa479...@archlinux.org> 
 > Content-Type: text/plain; charset="utf-8" 
 >  
 > On 06/04/2018 04:55 PM, pacman-dev via pacman-dev wrote: 
 > >  
 > > Hello Pacman Dev, The basic question first, is there a way to create 
 > > a tarball with .PKGINFO and use that tarball as a pacman package to 
 > > install files with particular permissions without also adding a 
 > > .MTREE file to that tarball? 
 > >  
 > > More context, currently we install files into our servers using a 
 > > bash script.  It pops open a tarball, keeping the users, groups, 
 > > permissions, times for the files in the tarball, then it copies each 
 > > file to the filesystem according to their location in the tarball. 
 > > It works great for a cheap slightly better then POC solution.  That 
 > > tarball and a pacman pkg file are vary similar in that those are both 
 > > tar files, with the files listed according to their desired location 
 > > on the filesystem.So my idea was that it would be relatively easy 
 > > for me to add the appropriate .PKGINFO into the tarball and switch 
 > > from using my bash script to using pacman itself.  This all worked 
 > > great, except for users.  In this case the file was created, in the 
 > > right place, with the right permissions but the wrong user and group. 
 >  
 > I'd suggest you have two choices to proceed from here: 
 > - use makepkg to repackage your tarball 
 > - generate the .MTREE which pacman expects 
 >  
 > The .MTREE is simple to make, this is where makepkg generates it: 
 > https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in?h=v5.1.0#n763
 >  
 >  
 > As you can see, it's really just bsdtar --format=mtree with a couple 
 > other options. 
 >  
 > --  
 > Eli Schwartz 
 > Bug Wrangler and Trusted User 
 >  
 > -- next part -- 
 > A non-text attachment was scrubbed... 
 > Name: signature.asc 
 > Type: application/pgp-signature 
 > Size: 833 bytes 
 > Desc: OpenPGP digital signature 
 > URL: 
 > <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20180604/fb33f22b/attachment-0001.asc>
 >  
 >  
 > -- 
 >  
 > Message: 6 
 > Date: Mon, 4 Jun 2018 17:03:28 -0400 
 > From: Andrew Gregory  
 > To: Discussion list for pacman development  
 > Subject: Re: [pacman-dev] pacman user+group support without mtree 
 > Message-ID: <20180604210327.GA604@b42-desktop.localdomain> 
 > Content-Type: text/plain; charset=us-ascii 
 >  
 > On 06/04/18 at 05:01pm, Eli Schwartz wrote: 
 > > On 06/04/2018 04:55 PM, pacman-dev via pacman-dev wrote: 
 > > >  
 > > > Hello Pacman Dev, The basic question first, is there a way to create 
 > > > a tarball with .PKGINFO and use that tarball as a pacman package to 
 > > > install files with particular permissions without also adding a 
 > > > .MTREE file to that tarball? 
 > > >  
 > > > More context, currently we install files into our servers using a 
 > > > bash script.  It pops open a tarball, keeping the users, groups, 
 > > > permissions, times for the files in the tarball, then it copies each 
 > > > file to the filesystem according to their location in the tarball. 
 > > > It works great for a cheap slightly better then POC solution.  That 
 > > > tarball and a pacman pkg file are vary similar in that those are both 
 > > > tar