On 06.03.2017 17:48, Andrew Gregory wrote:
On 03/06/17 at 05:40pm, Armin K. wrote:
On 06.03.2017 14:45, Andrew Gregory wrote:
On 03/06/17 at 10:12am, Armin K. wrote:
On 06.03.2017 00:17, Armin K. wrote:
On 06.03.2017 00:10, Allan McRae wrote:
On 06/03/17 09:04, Armin K. wrote:
On 06.03.2017 00:00, Allan McRae wrote:
Entries are alright in .MTREE (correct gid's). I don't suppose pacman
does something odd there? Why doesn't it use those uid's/gid's?

If you could point me to the part in the pacman code which does the
extraction, I might be able to find a solution (at least for myself).


Extraction is just taking files out of the tarball.  Note that the
tarball store files with UID/GID numbers and not names.

A


Oh my. Something else is at play here. Manually extracted tarball
contains wrong permissions, .MTREE file reports correct permissions.

pkg/ directory is sadly only owned by the build user. I suppose
something between package() and the tarball creation (or just
the tarball creation) screws things up. Any ideas what it might be?

libarchive version is 3.3.0.
fakeroot is 1.20.1.

This is indeed libarchive/bsdtar problem. The permissions are just fine
when extracted in chroot, but not when extracted from outside of it.

Looks like behaviour changed, and that tarball stores uid/gid isn't
true (anymore). Directory owned by a certain user is owned by the
same user in and outside of chroot, besides two of them having different
uids/gids.

This sounds like the expected behavior.  The user/group names are
stored in the archive if they exist on the system building the package
and bsdtar will use the names rather than the id's by default when
extracting the archive.

apg


I've contacted libarchive devs and they suggested --numeric-owner bsdtar
option. It works just as I expect it to.

pacman already only uses the numeric id's during extraction.


It might be libarchive bug/feature. I've found 
archive_write_disk_set_standard_lookup()
which will force resolving uid/gid's if used. The trick is, version 3.3.0 I 
compiled
packman against, calls such function almost uncoditionally in 
archive_read_extract().

https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_extract.c#L49

Reply via email to