On Sat, Sep 5, 2015 at 8:46 AM, hasufell <[email protected]> wrote: > On 09/05/2015 02:42 PM, 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. >> >>> PMS is more about the content of the ebuilds, so presumably all >>> package managers could structure how patches are provided by the >>> user in whatefver way is most consistent with how they already >>> operate. >> >> Exactly, IMHO we should leave the details how this is implemented >> to the package manager (including the option not to implement it). >> This is of course open for discussion. >> > > Right, I don't even see a reason to make the patch location configurable > once it is implemented in package managers. > > This is really just about eutils.eclass. >
I wasn't suggesting that the configuration of the path be made a part of PMS. I was suggesting that somebody talk to the portage developers about how they intend to implement EAPI6 so that users don't have to go into their make.conf and change EPATCH_USER_SOURCE to EAPPY_USER_SOURCE or something silly like that, or more likely define both since pre-6 ebuilds will use one setting and post-6 ebuilds will use the other. I do realize that there is no technical constraint that forces us to be nice to our users. It's just good manners. :) (And I do realize that portage isn't the only package manager out there. By all means try to do this in a way that is easiest on users of all of them.) -- Rich
