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...