| 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/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED NEEDINFO | ||
| 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
2013-04-28 16:49:31 UTC
We can't know this for sure up-front, though, can we? 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. How does this interact with binaries? And how does it interact with the user being wrong? 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. 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. 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}?
That sounds very very fragile... Can't we do all this in pkg_preinst? If pkg_preinst is allowed to apply the extended attributes to ${D}, then that should suffice, at least for the purposes of bug 460810.
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. (In reply to comment #9) it's already handled via a USE flag. no one is talking about dropping that part. 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.
(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. No progress since 8 years, and it seems unclear how this would be implemented. Feel free to reopen with a patch for PMS. |
