On 09/05/2015 06:14 PM, Guilherme Amadio wrote: > On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote: >>>>>>> On Sat, 5 Sep 2015, Rich Freeman wrote: >> >>> I certainly support the principle, but for the sake of transparency >>> can we try to coordinate this so that the setting name doesn't >>> change when this moves into the package manager for EAPI6? >> >> So far, the EAPI 6 draft says [1]: >> >> eapply_user >> Takes no arguments. Package managers supporting it apply >> user-provided patches to the source tree in the current working >> directory. Exact behaviour is implementation defined and beyond >> the scope of this specification. Package managers not supporting >> it must implement the function as a no-op. Only available in >> EAPIs listed in table [...] as supporting eapply_user. > > Is there a reason to pick eapply_user rather than epatch_user? I think > the second one would fit better with what we already have. > Alternatively, if we would like to avoid adding a new function, it could > be something like epatch --user or epatch -d $DIRECTORY_WITH_PATCHES, > where $DIRECTORY_WITH_PATCHES either defaults to something like > $EPATCH_SOURCE_USER, or can be specified via package.env. This takes the > burden away from the package manager for where to put patches, and lets > the user make that choice. >
Please start a new thread for discussing EAPI-6 features. This is offtopic here.
