PKGBUILD literally chown root:root $pkgdir/foo [solved]

graysky · 2019-11-10 12:26:04

Is it possible to tell makepkg that the contents of $pkgdir/foo are to be owned by root:root?

Use case: I am currently directly calling bsdtar in the package function to extract contents to $pkgdir/opt/. In the final package, the permissions of /opt/foo are those of the user who ran makepkg.

The PKGBUILD in question is here.

One solution is to just not use a noextract= and use a cp -a command but I have several reasons for not wanting to do that:

1) The source tarballs contain pre-compiled toolchains specific to an architecture
2) I currently each source tarball uses the identical directory structure so one would just overwrite the other
3) Extracting both is wasteful since we can only package one

Last edited by graysky (2019-11-10 21:42:24)

Trilby · 2019-11-10 13:11:21

graysky wrote:

I am currently directly calling bsdtar in the package function to extract contents to $pkgdir/opt/. In the final package, the permissions of /opt/foo are those of the user who ran makepkg.

`man bsdtar` then see --uid and --gid.

graysky · 2019-11-10 14:08:18

Trilby wrote:

`man bsdtar` then see --uid and --gid.

Thanks for the tip... I must not be applying these correctly as the corresponding output is still in my user's name/group.

mkdir test
bsdtar -x --uid 0 --gid 0 -f x-tools86-aarch64-20191105.tar.zst -C test

Last edited by graysky (2019-11-10 14:11:08)

progandy · 2019-11-10 14:32:46

Edit: Of course, --gid and --uid will only work inside a fakeroot environment (which the package() function is)

If you extract the archive before the fakeroot, then everything will be owned by your username. After starting the fakeroot, your name will be equal with root. (that is why extracting during prepare()/build() and creating the archive in package() later works). If bsdtar thinks it is running as root, then it tries to preserve the username it finds inside an archive and fakeroot makes that possible until it is closed. I'm not sure how it translates unavailable names from the archive into your build user, though. (Maybe same UID?) You can force a specific user/group with uig/gid.

Last edited by progandy (2019-11-10 15:01:32)

Trilby · 2019-11-10 14:47:44

I see it isn't working as I thought it should.

But does it matter. I just confirmed this is normal in other packages: the content under /pkg/$pkgname normally is owned by whoever ran makepkg. But once installed they are owned by root.

Tangential notes:

Why are you downloading sources that are not used? Use architecture-specific source arrays, and by assigning a common filename to each potential download, you could get rid of the use of $CARCH in the package function.

What is line 42 of the PKGBUILD doing / supposed to do? That seems to be creating symbolic links that would eventually resolve to /usr/distcc. Are these meant to point to /usr/bin/distcc?

Last edited by Trilby (2019-11-10 15:08:44)

graysky · 2019-11-10 21:36:45

Thanks for the replies and helpful suggestions! I believe we got 9.2.0-4 working as expected now.

@trilby - Good catch on the symlinks, yes, they needed to link back to /usr/bin/distcc. Thanks for reminding me about the arch-specific source arrays as well.

progandy · 2019-11-10 22:54:00

ln -sf /usr/bin/distcc "${pkgdir}/usr/lib/distcc/x86_64-pc-linux-gnu-$bin"

That looks wrong to me, the target should include the binary name, not only the directory.
Edit: Sorry, I guess distcc is the binary.

Relative links are possible, but then it should be "../../bin/distcc" I think.

Last edited by progandy (2019-11-10 22:56:01)

Trilby · 2019-11-10 23:32:42

Yes, relative links would be possible, but I've always found them a bit ugly and confusing. In the original PKGBUILD something look wrong on that line, but I wasn't quite sure at first where the link would actually point. Before I even typed my note above, I had to create a few nested directories and do some trial and error to actually confirm. Links to actual path are just much more clear and obvious.

The advantage to relative links would be if they were within the same package/project, the upstream author would not need to care what the final DESTDIR was, a relative link under /usr would work the same as under /usr/local or /opt or anywhere else. But as these are linking across to an independent project that is not relevant.

Last edited by Trilby (2019-11-10 23:34:18)

Arch Linux

#1 2019-11-10 12:26:04

PKGBUILD literally chown root:root $pkgdir/foo [solved]

#2 2019-11-10 13:11:21

Re: PKGBUILD literally chown root:root $pkgdir/foo [solved]

#3 2019-11-10 14:08:18

Re: PKGBUILD literally chown root:root $pkgdir/foo [solved]

#4 2019-11-10 14:32:46

Re: PKGBUILD literally chown root:root $pkgdir/foo [solved]

#5 2019-11-10 14:47:44

Re: PKGBUILD literally chown root:root $pkgdir/foo [solved]

#6 2019-11-10 21:36:45

Re: PKGBUILD literally chown root:root $pkgdir/foo [solved]

#7 2019-11-10 22:54:00

Re: PKGBUILD literally chown root:root $pkgdir/foo [solved]

#8 2019-11-10 23:32:42

Re: PKGBUILD literally chown root:root $pkgdir/foo [solved]

Board footer