| Summary: | MERGE_TYPE phases aren't defined | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Brian Harring (RETIRED) <ferringb> |
| Component: | PMS/EAPI | Assignee: | Package Manager Specification <pms> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
(In reply to comment #0) > We never locked down the phases MERGE_TYPE were available during; Yes we did. It's legal in pkg_*: <http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-119002> > I'm wary of it being available in pkg_pretend since I could see an ebuild > author blocking merging something as a binpkg via it See bug 347351 comment #1 on why the variable can be useful in pkg_pretend(). One of these days I'm going to figure out why my ability to search pms rendered doc sucks oh-so-very-much. pkg_config for MERGE_TYPE (same for pkg_info) is kind of redundant, unless it's mandated we track that level of info (vs tracking the repo it originated from)... (In reply to comment #1) > (In reply to comment #0) > > We never locked down the phases MERGE_TYPE were available during; > > Yes we did. > It's legal in pkg_*: <http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-119002> Er, in pkg_config and pkg_info as well? We need to refactor PMS to have some classification of phases so we can stop saying pkg_*... "Source phases", "Install phases", "Uninstall phases", "Special Installed phases", "Special Not Installed phases" or something. No progress since 2011. Feel free to reopen with a patch attached. |
We never locked down the phases MERGE_TYPE were available during; src_* technically is valid right now, although I've seen no such usage. Offhand, pkg_setup, pkg_{pre,post}* come to mind; I'm wary of it being available in pkg_pretend since I could see an ebuild author blocking merging something as a binpkg via it (while that's insane, folks due insane shit in ebuilds, no interest in enabling the more special usages). Thoughts/comments? I'd prefer this to be retroactive for EAPI4, although it depends on the fallout- likely none, but still.