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 totally. > 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(). -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com