---- On Mon, 04 Jun 2018 14:03:41 -0700 <[email protected]> wrote ---- > Send pacman-dev mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: [email protected] > Subject: [pacman-dev] [PATCH] PKGBUILD.5: document restriction on > pkgrel > Message-ID: <[email protected]> > > 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 <[email protected]> > --- > > 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 <[email protected]> > To: Discussion list for pacman development <[email protected]> > Subject: Re: [pacman-dev] [PATCH] makepkg: Treat pkgrel more similarly > to pkgver > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > On 04/06/18 06:01, Luke Shumaker wrote: > > From: Luke Shumaker <[email protected]> > > > > 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 <[email protected]> > > --- > > 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 <[email protected]> > To: [email protected] > Subject: [pacman-dev] [PATCH] makepkg: fix erroneous $BUILDDIR when > $startdir is not an absolute path > Message-ID: <[email protected]> > > 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 <[email protected]> > --- > 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 <[email protected]> > To: "pacman-dev" <[email protected]> > Subject: [pacman-dev] pacman user+group support without mtree > Message-ID: > <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: [pacman-dev] pacman user+group support without mtree > Message-ID: <[email protected]> > 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 <[email protected]> > To: Discussion list for pacman development <[email protected]> > Subject: Re: [pacman-dev] pacman user+group support without mtree > Message-ID: <[email protected]> > 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
