[pacman-dev] pacman-dev Digest, Vol 153, Issue 9
pacman-dev
pacman-dev at dodtsair.com
Mon Jun 4 23:04:58 UTC 2018
---- On Mon, 04 Jun 2018 14:03:41 -0700 <pacman-dev-request at archlinux.org> wrote ----
> Send pacman-dev mailing list submissions to
> pacman-dev at 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 at archlinux.org
>
> You can reach the person managing the list at
> pacman-dev-owner at 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 at archlinux.org>
> To: pacman-dev at archlinux.org
> Subject: [pacman-dev] [PATCH] PKGBUILD.5: document restriction on
> pkgrel
> Message-ID: <20180604125002.2806-1-allan at 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 at 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 at archlinux.org>
> To: Discussion list for pacman development <pacman-dev at archlinux.org>
> Subject: Re: [pacman-dev] [PATCH] makepkg: Treat pkgrel more similarly
> to pkgver
> Message-ID: <06a21712-d07b-c992-1584-91684ae879d8 at archlinux.org>
> Content-Type: text/plain; charset=windows-1252
>
> On 04/06/18 06:01, Luke Shumaker wrote:
> > From: Luke Shumaker <lukeshu at 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 at 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 at archlinux.org>
> To: pacman-dev at archlinux.org
> Subject: [pacman-dev] [PATCH] makepkg: fix erroneous $BUILDDIR when
> $startdir is not an absolute path
> Message-ID: <20180604133119.16049-1-eschwartz at 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 at 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 at dodtsair.com>
> To: "pacman-dev" <pacman-dev at archlinux.org>
> Subject: [pacman-dev] pacman user+group support without mtree
> Message-ID:
> <163cc95155a.c10d90fa104952.6720902778935437783 at 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 at archlinux.org>
> To: pacman-dev at archlinux.org
> Subject: Re: [pacman-dev] pacman user+group support without mtree
> Message-ID: <427232e1-ae1f-fafd-7e82-6c34fa47968a at 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 <andrew.gregory.8 at gmail.com>
> To: Discussion list for pacman development <pacman-dev at archlinux.org>
> Subject: Re: [pacman-dev] pacman user+group support without mtree
> Message-ID: <20180604210327.GA604 at 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#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.
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
More information about the pacman-dev
mailing list