[gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses

[gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 1406 bytes --]

In pre-EAPI-2, src_unpack phase was the most logical phase to be provided by 
SCM eclasses, thus classes has been set up to export ${ECLASS}_src_unpack.

This phase in most (if not all) SCM eclasses provided:
- unpack functionality - fetch and store in ${DISTDIR}
- bootstrap functionality - either patching or bootstrapping just unpacked 
sourced with command

In EAPI-2, bootstrap functionality belongs to prepare phase, thus it's been 
moved there - SCM eclasses in EAPI-2 codepath has been set up to provide 
src_prepare.

And this is the problem (some people may be even unaware of it).
In pre EAPI-2 it was sufficient to do the following in live ebuilds:

inherit ${some_eclass} ${scm_eclass}

${scm_eclass} inherited as last one, would just shadow src_unpack, providing 
what we want. In EAPI-2 however, it as well shadows src_prepare which is in 
*most* cases unwelcome, especially if one uses autopatcher (base.eclass, so 
cmake-utils.eclass, kde4-*.eclass, and probably some other).

Because SCM bootstrap is either not used at all, or used very rarely, there's 
suggestion to:
- either drop it
- or (preferably) to make SCM eclasses export src_prepare only on specific 
request
- or to make it easier - to not export it at all - thus making it required for 
developer to intentionally invoke ${ECLASS}_src_prepare if bootstrapping is 
required.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses

[Ulrich Mueller]

>>>>> On Thu, 24 Sep 2009, Maciej Mrozowski wrote:

> Because SCM bootstrap is either not used at all, or used very
> rarely, there's suggestion to:
> - either drop it
> - or (preferably) to make SCM eclasses export src_prepare only on
>   specific request
> - or to make it easier - to not export it at all - thus making it
>   required for developer to intentionally invoke
>   ${ECLASS}_src_prepare if bootstrapping is required.

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.

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?

Ulrich

Re: [gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 3025 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses

[Donnie Berkholz]

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

[gentoo-dev] Re: [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Thu, 24 Sep 2009 03:39:26 +0200
Maciej Mrozowski <reavertm@poczta.fm> wrote:

> And this is the problem (some people may be even unaware of it).
> In pre EAPI-2 it was sufficient to do the following in live ebuilds:
> 
> inherit ${some_eclass} ${scm_eclass}
> 
> ${scm_eclass} inherited as last one, would just shadow src_unpack, providing 
> what we want.

Oogh, no.  Relying on ordering of the inherit line is never a good idea.  If
you need to call scm_src_unpack, call scm_src_unpack.

> Because SCM bootstrap is either not used at all, or used very rarely, there's 
> suggestion to:
> - either drop it
> - or (preferably) to make SCM eclasses export src_prepare only on specific 
> request
> - or to make it easier - to not export it at all - thus making it required for 
> developer to intentionally invoke ${ECLASS}_src_prepare if bootstrapping is 
> required.

Why not do number 3 but call it ${ECLASS}_bootstrap?  If people need it they
can call it from src_prepare.


-- 
fonts,                             Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]