Re: [pacman-dev] pacman-dev Digest, Vol 153, Issue 9
---- On Mon, 04 Jun 2018 14:03:41 -0700 <pacman-dev-request@archlinux.org> wrote ----
Send pacman-dev mailing list submissions to pacman-dev@archlinux.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.archlinux.org/listinfo/pacman-dev or, via email, send a message with subject or body 'help' to pacman-dev-request@archlinux.org
You can reach the person managing the list at pacman-dev-owner@archlinux.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of pacman-dev digest..."
Today's Topics:
1. [PATCH] PKGBUILD.5: document restriction on pkgrel (Allan McRae) 2. Re: [PATCH] makepkg: Treat pkgrel more similarly to pkgver (Allan McRae) 3. [PATCH] makepkg: fix erroneous $BUILDDIR when $startdir is not an absolute path (Eli Schwartz) 4. pacman user+group support without mtree (pacman-dev) 5. Re: pacman user+group support without mtree (Eli Schwartz) 6. Re: pacman user+group support without mtree (Andrew Gregory)
----------------------------------------------------------------------
Message: 1 Date: Mon, 4 Jun 2018 22:50:02 +1000 From: Allan McRae <allan@archlinux.org> To: pacman-dev@archlinux.org Subject: [pacman-dev] [PATCH] PKGBUILD.5: document restriction on pkgrel Message-ID: <20180604125002.2806-1-allan@archlinux.org>
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 <allan@archlinux.org> ---
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
------------------------------
Message: 2 Date: Mon, 4 Jun 2018 22:52:57 +1000 From: Allan McRae <allan@archlinux.org> To: Discussion list for pacman development <pacman-dev@archlinux.org> Subject: Re: [pacman-dev] [PATCH] makepkg: Treat pkgrel more similarly to pkgver Message-ID: <06a21712-d07b-c992-1584-91684ae879d8@archlinux.org> Content-Type: text/plain; charset=windows-1252
On 04/06/18 06:01, Luke Shumaker wrote:
From: Luke Shumaker <lukeshu@parabola.nu>
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 <lukeshu@parabola.nu> ---
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
------------------------------
Message: 3 Date: Mon, 4 Jun 2018 09:31:19 -0400 From: Eli Schwartz <eschwartz@archlinux.org> To: pacman-dev@archlinux.org Subject: [pacman-dev] [PATCH] makepkg: fix erroneous $BUILDDIR when $startdir is not an absolute path Message-ID: <20180604133119.16049-1-eschwartz@archlinux.org>
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 <eschwartz@archlinux.org> --- 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
------------------------------
Message: 4 Date: Mon, 04 Jun 2018 13:55:12 -0700 From: pacman-dev <pacman-dev@dodtsair.com> To: "pacman-dev" <pacman-dev@archlinux.org> Subject: [pacman-dev] pacman user+group support without mtree Message-ID: <163cc95155a.c10d90fa104952.6720902778935437783@dodtsair.com> Content-Type: text/plain; charset="UTF-8"
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
------------------------------
Message: 5 Date: Mon, 4 Jun 2018 17:01:22 -0400 From: Eli Schwartz <eschwartz@archlinux.org> To: pacman-dev@archlinux.org Subject: Re: [pacman-dev] pacman user+group support without mtree Message-ID: <427232e1-ae1f-fafd-7e82-6c34fa47968a@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#n76...
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 <andrew.gregory.8@gmail.com> To: Discussion list for pacman development <pacman-dev@archlinux.org> 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 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#n76...
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.
I see, in particular you are saying that pacman uses the uid not the user name. Hence I should be using the --numeric-owner flag on tar when inspecting the package: $ tar --numeric-owner -tvf vienna-os-scaffold-0.0.0-any.pkg.tar.xz | grep sbin/vienna -r-x------ 501/20 533 2017-12-04 13:18 usr/local/sbin/vienna Since the package is built with uid 501 which does not exist, and gid 20 which belongs to dialout then pacman installs the files with the corresponding ids, the names are ignored. $ grep dialout /etc/group dialout:x:20: $ grep 501 /etc/passwd $ $ ls -l /usr/local/sbin/vienna -r-x------ 1 501 dialout 533 Dec 4 13:18 /usr/local/sbin/vienna Solution for me is to build the tarball using uid and gid. Michael Power
participants (1)
-
pacman-dev