Summary: | Allow overriding the location of user_patches (ie restore EPATCH_USER_SOURCE) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ed Wildgoose <gentoo> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Ed Wildgoose
2019-01-10 15:37:23 UTC
Better name for a new variable would be USER_PATCHES_DIR or PORTAGE_USER_PATCHES_DIR. (In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > Better name for a new variable would be USER_PATCHES_DIR or > PORTAGE_USER_PATCHES_DIR. I'm not disagreeing, but my proposed change simply makes EAPI 6 ebuilds work the same as versions 0-5. Your rename is a great idea, but would require updating the documentation, deprecating the old name and possibly updating the older eclass code I think in the first instance I would prefer that we make the (very tiny) change in the EAPI6 class code so that the variable usage simply continues that of how it worked previously. What do you think? (In reply to Ed Wildgoose from comment #2) > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > > Better name for a new variable would be USER_PATCHES_DIR or > > PORTAGE_USER_PATCHES_DIR. > > I'm not disagreeing, but my proposed change simply makes EAPI 6 ebuilds work > the same as versions 0-5. Your rename is a great idea, but would require > updating the documentation Documentation of eclasses specifies behavior of eclasses, not package managers. Portage is not bound by design decisions made for eclasses. If it was otherwise, then e.g. successor of get_version_component_range (provided by versionator.eclass) could not named ver_cut (provided by package managers in EAPI >=7). |