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. Cheers, —Guilherme
