| 1 |
On 15:46 Thu 24 Sep , Maciej Mrozowski wrote: |
| 2 |
> Because autopatcher makes it able to specify patches that are version |
| 3 |
> independent (same patches for live and tagged ebuilds), while SCM |
| 4 |
> patching/bootstrapping may be used for some specific cases (I haven't seen any |
| 5 |
> yet personally, hence suggestions to drop it completely or disable by default |
| 6 |
> and not to export src_prepare). |
| 7 |
|
| 8 |
Patching not so much, but bootstrapping w/ eautoreconf/autogen.sh |
| 9 |
totally. |
| 10 |
|
| 11 |
> When migrating SCM eclasses to EAPI-2, I recommended leaving bootstrap in |
| 12 |
> src_unpack phase and not to move it to src_prepare because I was well aware it |
| 13 |
> will break most live EAPI-2 ebuilds having 'inherit <sth> <scm_eclass>'. And |
| 14 |
> because developers doing this change didn't care for that case, I don't see |
| 15 |
> why now they should oppose the idea to fix what they've broken, especially |
| 16 |
> when it's probably going to affect only bad live EAPI-2 ebuilds (with not |
| 17 |
> working PATCHES). |
| 18 |
> |
| 19 |
> But anyway, think for a while about the purpose of SCM eclasses. At least in |
| 20 |
> my opinion, they should only provide [tarball or SCM] -> SRCDIR delivery |
| 21 |
> method, so just unpack method - any source processing should be purely |
| 22 |
> *intentional* (and not enabled by default in SCM eclasses) - so in my opinion |
| 23 |
> - unconditionally shadowing src_prepare by SCM eclasses is just |
| 24 |
> architecturally wrong and needs to be fixed. |
| 25 |
|
| 26 |
The purpose of SCM eclasses, in my mind, is to provide an environment as |
| 27 |
similar as possible to that of a released tarball. That certainly |
| 28 |
includes bootstrapping. It gets annoying when I need to fiddle around |
| 29 |
with patching the build system if bootstrapping happens during |
| 30 |
src_unpack(). Then I end up patching during src_unpack(), which goes |
| 31 |
against the whole idea of src_prepare(). |
| 32 |
|
| 33 |
-- |
| 34 |
Thanks, |
| 35 |
Donnie |
| 36 |
|
| 37 |
Donnie Berkholz |
| 38 |
Developer, Gentoo Linux |
| 39 |
Blog: http://dberkholz.wordpress.com |
Archives