Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 467766

Summary: [Future EAPI] add support to query whether or not extended attributes (xattrs) are allowed
Product: Gentoo Hosted Projects Reporter: Zac Medico <zmedico>
Component: PMS/EAPIAssignee: PMS/EAPI <pms>
Status: CONFIRMED ---    
Severity: normal CC: esigra
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: All   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=364487
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 174380, 460810    

Description Zac Medico gentoo-dev 2013-04-28 16:49:31 UTC
For example, see bug #460810, where the ebuild's src_install behavior would need to vary depending on whether or not extended attributes are allowed.
Comment 1 Ciaran McCreesh 2013-04-28 16:56:09 UTC
We can't know this for sure up-front, though, can we?
Comment 2 Zac Medico gentoo-dev 2013-04-28 17:03:10 UTC
If the user asserts that extended attributes are allowed, and configures the package manager to be aware of this assertion, then the package manager can expose this assertion to the ebuild environment.
Comment 3 Ciaran McCreesh 2013-04-28 17:05:55 UTC
How does this interact with binaries? And how does it interact with the user being wrong?
Comment 4 Zac Medico gentoo-dev 2013-04-28 17:09:32 UTC
Behavior for binary packages is undefined by PMS, as usual. If the user is wrong, then the behavior is undefined, and the user must accept responsibility for configuring the package manager incorrectly.
Comment 5 Ciaran McCreesh 2013-04-28 17:12:37 UTC
Undefined by PMS, sure, but we still need to implement this feature in a way that doesn't prevent package manglers from doing binaries sanely. If this kind of thing is done in src_*, it implies that you'll need to know at binary-build time what you're installing to.
Comment 6 Zac Medico gentoo-dev 2013-04-28 17:18:39 UTC
How about if we let the user's assertion that extended attributes are allowed imply that "what you're installing to" has equivalent properties to the directory referenced by ${D}?
Comment 7 Ciaran McCreesh 2013-04-28 17:23:13 UTC
That sounds very very fragile... Can't we do all this in pkg_preinst?
Comment 8 Zac Medico gentoo-dev 2013-04-28 17:32:08 UTC
If pkg_preinst is allowed to apply the extended attributes to ${D}, then that should suffice, at least for the purposes of bug 460810.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-04-28 18:12:55 UTC
I'd say this is something that should be handled via a USE flag, if at all in that way. Then, please don't put all kinds of xattrs into one bag. For example, some fs may have ACL support without caps support, so a generic 'xattr' wouldn't be really helpful.
Comment 10 SpanKY gentoo-dev 2013-04-28 18:17:55 UTC
(In reply to comment #9)

it's already handled via a USE flag.  no one is talking about dropping that part.
Comment 11 Zac Medico gentoo-dev 2013-04-29 16:10:13 UTC
We could add a boolean returning function called xattr_allowed, and have it return true if xattrs are allowed in ${D} for the current phase. If we only want to support pkg_preinst, then PMS can say that this function may only return true during pkg_preinst.

Alternatively, we could add a more specific function called preinst_xattr_allowed.
Comment 12 SpanKY gentoo-dev 2013-04-29 18:31:14 UTC
(In reply to comment #11)

doing as much work as possible in src_install is desirable.  the pkg_preinst phase would only be needed to process the fallback logic.  so if the PM takes note of the xattrs set in $D after src_install, and it detects it can save/restore/transfer to the final $ROOT, then the logic in pkg_preinst would be a simple nop.