>>>>> On Sat, 17 Oct 2015, Alexis Ballier wrote: > Sorry for coming very late on this, but what is the rationale behind > setting in stone an 'eapply' different to an 'epatch' that has been > widely tested for decades now ? Or even defining eapply in PMS ?
The rationale is that we cannot apply patches in the default src_prepare() unless there is a patch function in the package manager itself. Obviously the default phase cannot call a function from an eclass. > I can understand "eapply is a function that applies patches" isn't nice > for a spec., but we've already seen in the past gnu patch changing > behavior wrt what is an acceptable patch between versions, bsd 'patch' > command behaves slightly differently than gnu patch (read: is unusable > with epatch), etc. > One can argue that gnu patch changing behavior is part of life, but > what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd patch, > 'gpatch' is gnu patch; we use profile.bashrc to alias patch to gpatch > for ebuilds, but I don't think profile.bashrc should mess up with what > is mandated by PMS. The spec for eapply mentions that it will accept GNU patch options, but maybe we should be more explicit and say that eapply must call GNU patch. > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y' extracts > -p0 patches by default here. Or when $S is actually a subdir of a > repository, this will make standard git format-patch generated patches > unusable. Limiting the level to -p1 (and not doing autodetection) was a design decision. eapply is really meant for simple cases like default src_prepare applying patches listed in the PATCHES variable. For anything that is more complicated there will still be epatch. Ulrich
pgpEZQre97p85.pgp
Description: PGP signature
