The ebuild documentation implies that I can set EPATCH_USER_SOURCE to override the location where I store local patches. This appears to be true for EAPI up to version 5, but not for version 6. Up to version 5 the code is in portage eclass/epatch.class and references EPATCH_USER_SOURCE, # @VARIABLE: EPATCH_USER_SOURCE # @DESCRIPTION: # Location for user patches, see the epatch_user function. # Should be set by the user. Don't set this in ebuilds. : ${EPATCH_USER_SOURCE:=${PORTAGE_CONFIGROOT%/}/etc/portage/patches} However, in EAPI 6 the relevant code is defined in ..python../phase-helpers.sh, here we find: if ___eapi_has_eapply_user; then eapply_user() { [[ ${EBUILD_PHASE} == prepare ]] || \ die "eapply_user() called during invalid phase: ${EBUILD_PHASE}" # keep path in __dyn_prepare in sync! local tagfile=${T}/.portage_user_patches_applied [[ -f ${tagfile} ]] && return >> "${tagfile}" local basedir=${PORTAGE_CONFIGROOT%/}/etc/portage/patches So there is a hardcoded location and we cannot override it in make.conf My use case is that I build a large (ish) number of virtual machines and I want to maintain a common "patches" directory in my custom profile. This currently requires an (error prone) solution to setup symlinks in every situation to the relevant patches location. Being able to set this in make.conf (as is possible in EAPI 5 or below) would be preferred Feature request: Amend the code above to be something like: : ${EPATCH_USER_SOURCE:=${PORTAGE_CONFIGROOT%/}/etc/portage/patches} local basedir=${EPATCH_USER_SOURCE} Thanks for listening
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).
