On Thursday 24 of September 2009 08:32:53 Ulrich Mueller wrote:
It's all about making live - tagged ebuild synchronization easier.
Currently
Not a good idea, IMHO. In pre-EAPI-2, the SCM eclasses shadow
src_unpack of base.eclass, so also no autopatching of base.eclass
takes place. If we now change it _not_ to export src_prepare, then
there may be surprises when bumping an ebuild to EAPI-2.
I think only those will be surprised, who declare PATCHES variable
and who don't make use of it. To ensure we're on the same page, autopatcher
is:
PATCHES=(
${FILESDIR}/patch1
${FILESDIR}/patch2
)
accompanied with invocation of base_src_prepare (EAPI-2) or base_src_unpack
(pre-EAPI-2).
And when bumping ebuild EAPI one is required anyway to verify whether patches
are applicable, proper phases are invoked etc.
The only other people who are going to be surprised would be those who rely on
current implicit SCM src_prepare behaviour but I'm yet to find anyone with
such ebuild.
Actually *now* there's surprise factor all the time when using tagged EAPI-2
ebuild to create live EAPI-2 ebuild as it requires either explicitly
overriding src_prepare or src_unpack, because when you just place
'inherit someeclass git'
PATCHES=(file1 file2)
it will shadow src_prepare and *silently* ignore autopatcher you may think
you're using (hey, PATCHES variable is there!). Current situation makes live
- tagged ebuild synchronization a bit less convenient and certainly more
tricky.
Besides, most SCM eclasses (at least cvs, subversion, git and bzr)
have their own autopatch facility running in src_prepare (before
bootstrap). Why would one need _both_ this and the one in base.eclass?
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).
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.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
