On 15:46 Thu 24 Sep     , Maciej Mrozowski wrote:
> Because autopatcher makes it able to specify patches that are version 
> independent (same patches for live and tagged ebuilds), while SCM 
> patching/bootstrapping may be used for some specific cases (I haven't seen 
> any 
> yet personally, hence suggestions to drop it completely or disable by default 
> and not to export src_prepare).

Patching not so much, but bootstrapping w/ eautoreconf/autogen.sh 

> When migrating SCM eclasses to EAPI-2, I recommended leaving bootstrap in 
> src_unpack phase and not to move it to src_prepare because I was well aware 
> it 
> will break most live EAPI-2 ebuilds having 'inherit <sth> <scm_eclass>'. And 
> because developers doing this change didn't care for that case, I don't see 
> why now  they should oppose the idea to fix what they've broken, especially 
> when it's probably going to affect only bad live EAPI-2 ebuilds (with not 
> working PATCHES).
> But anyway, think for a while about the purpose of SCM eclasses. At least in 
> my opinion, they should only provide [tarball or SCM] -> SRCDIR delivery 
> method, so just unpack method - any source processing should be purely 
> *intentional* (and not enabled by default in SCM eclasses) - so in my opinion 
> - unconditionally shadowing src_prepare by SCM eclasses is just 
> architecturally wrong and needs to be fixed.

The purpose of SCM eclasses, in my mind, is to provide an environment as 
similar as possible to that of a released tarball. That certainly 
includes bootstrapping. It gets annoying when I need to fiddle around 
with patching the build system if bootstrapping happens during 
src_unpack(). Then I end up patching during src_unpack(), which goes 
against the whole idea of src_prepare().


Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

Reply via email to