| Summary: | sys-apps/install-xattr - allow installing files from filesystems without xattr | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jaak Ristioja <jaak> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | UNCONFIRMED --- | ||
| Severity: | enhancement | CC: | base-system, opal, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
If the Gentoo repository (i.e. /var/db/repos/gentoo) is on a filesystem without xattr support, emerging packages like net-mail/mailbase or app-arch/tar fails on hardened (i.e. default/linux/amd64/17.1/no-multilib/hardened), due to install-xattr failing to retrieve the extended attributes of certain files: install-xattr: listxattr() failed: Operation not supported According to strace: listxattr("/var/tmp/portage/net-mail/mailbase-1.5-r2/files/mailcap.5", NULL, 0) = -1 EOPNOTSUPP (Operation not supported) where /var/tmp/portage/net-mail/mailbase-1.5-r2/files is actually a symlink to /var/db/repos/gentoo/net-mail/mailbase/files during the merge. During debugging this I wasted quite a lot of time trying to figure out what is wrong with the xattr support on my /var/tmp/portage/ filesystem (which does have xattr support) before I found that the FILESDIR was actually a symlink to the other filesystem. Please add support for repositories on filesystems without xattr or provide better diagnostics. Should extended attributes from files residing on different filesystems than ${PORTAGE_BUILDDIR} at all be considered for copying? Thanks!