Summary: | [Future EAPI] Support dynamic EAPIs via unsetting of the EAPI= variable | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | zachariah.cabelly |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
zachariah.cabelly
2022-08-08 18:20:53 UTC
I don't believe that this would be possible in a well-defined way. New EAPIs can come with changes in function behaviour (e.g. econf and insopts in EAPI 8) or with different defaults for phase functions (e.g. default_src_install has changed several times). Neither of these are detectable by the package manager looking at the ebuild. Also, there is no guarantee that an ebuild in a future EAPI would even be parseable by an old package manager. Sourcing it may error out because of a different Bash version (or we may even decide to switch to something other than Bash). Not only what ulm said, but this would also add a heavy burden onto implementations and mean a reliance on heuristics that would move us away from formal, well-defined semantics/behaviour. I think we'd be better off with hearing what issue you had with your ebuild:
>Mess-ups like the ebuild to update the Zen Kernel I tried to upload could also be avoided.
|