| 1 |
On Thursday 24 of September 2009 08:32:53 Ulrich Mueller wrote: |
| 2 |
|
| 3 |
It's all about making live <-> tagged ebuild synchronization easier. |
| 4 |
Currently |
| 5 |
|
| 6 |
> Not a good idea, IMHO. In pre-EAPI-2, the SCM eclasses shadow |
| 7 |
> src_unpack of base.eclass, so also no autopatching of base.eclass |
| 8 |
> takes place. If we now change it _not_ to export src_prepare, then |
| 9 |
> there may be surprises when bumping an ebuild to EAPI-2. |
| 10 |
|
| 11 |
I think only those will be surprised, who declare PATCHES variable |
| 12 |
and who don't make use of it. To ensure we're on the same page, autopatcher |
| 13 |
is: |
| 14 |
|
| 15 |
PATCHES=( |
| 16 |
"${FILESDIR}/patch1" |
| 17 |
"${FILESDIR}/patch2" |
| 18 |
) |
| 19 |
|
| 20 |
accompanied with invocation of base_src_prepare (EAPI-2) or base_src_unpack |
| 21 |
(pre-EAPI-2). |
| 22 |
And when bumping ebuild EAPI one is required anyway to verify whether patches |
| 23 |
are applicable, proper phases are invoked etc. |
| 24 |
|
| 25 |
The only other people who are going to be surprised would be those who rely on |
| 26 |
current implicit SCM src_prepare behaviour but I'm yet to find anyone with |
| 27 |
such ebuild. |
| 28 |
|
| 29 |
Actually *now* there's surprise factor all the time when using tagged EAPI-2 |
| 30 |
ebuild to create live EAPI-2 ebuild as it requires either explicitly |
| 31 |
overriding src_prepare or src_unpack, because when you just place |
| 32 |
|
| 33 |
'inherit someeclass git' |
| 34 |
|
| 35 |
PATCHES=("file1" " file2") |
| 36 |
|
| 37 |
it will shadow src_prepare and *silently* ignore autopatcher you may think |
| 38 |
you're using (hey, PATCHES variable is there!). Current situation makes live |
| 39 |
<-> tagged ebuild synchronization a bit less convenient and certainly more |
| 40 |
tricky. |
| 41 |
|
| 42 |
> Besides, most SCM eclasses (at least cvs, subversion, git and bzr) |
| 43 |
> have their own autopatch facility running in src_prepare (before |
| 44 |
> bootstrap). Why would one need _both_ this and the one in base.eclass? |
| 45 |
|
| 46 |
Because autopatcher makes it able to specify patches that are version |
| 47 |
independent (same patches for live and tagged ebuilds), while SCM |
| 48 |
patching/bootstrapping may be used for some specific cases (I haven't seen any |
| 49 |
yet personally, hence suggestions to drop it completely or disable by default |
| 50 |
and not to export src_prepare). |
| 51 |
|
| 52 |
When migrating SCM eclasses to EAPI-2, I recommended leaving bootstrap in |
| 53 |
src_unpack phase and not to move it to src_prepare because I was well aware it |
| 54 |
will break most live EAPI-2 ebuilds having 'inherit <sth> <scm_eclass>'. And |
| 55 |
because developers doing this change didn't care for that case, I don't see |
| 56 |
why now they should oppose the idea to fix what they've broken, especially |
| 57 |
when it's probably going to affect only bad live EAPI-2 ebuilds (with not |
| 58 |
working PATCHES). |
| 59 |
|
| 60 |
But anyway, think for a while about the purpose of SCM eclasses. At least in |
| 61 |
my opinion, they should only provide [tarball or SCM] -> SRCDIR delivery |
| 62 |
method, so just unpack method - any source processing should be purely |
| 63 |
*intentional* (and not enabled by default in SCM eclasses) - so in my opinion |
| 64 |
- unconditionally shadowing src_prepare by SCM eclasses is just |
| 65 |
architecturally wrong and needs to be fixed. |
| 66 |
|
| 67 |
-- |
| 68 |
regards |
| 69 |
MM |
Archives