Re: OE-Core and Bitbake wrapper changes (min 2.7.3 python version)

[Mark Hatle <mark.hatle@windriver.com>]

On 6/7/13 5:47 AM, Richard Purdie wrote:
> Its not secret that I hate the current bitbake wrapper script and want
> to remove it for 101 different reasons.
>
> I now have code which removes the need for the double execution of
> bitbake which was the only fundamental reason we had it. The question
> therefore remains, what to do with the other pieces of the wrapper,
> specifically the tar and git versions checks.
>
> As a reminder for those who don't remember the problem here, the git
> version is checked since we use certain parameters in the git fetcher
> which need certain versions of git and git is in ASSUME_PROVIDED these
> days. Its possible to trigger git operations at part time to resolve
> revisions. tar is even more ugly since the wrong version has issues
> extracting sstate archives. These issues mean injecting building them
> into the dependency chain at the right point is hard.
>
> Personally, I think we carry around a bit too much legacy these days and
> its starting to hurt us. I would therefore like to propose that we take
> this opportunity to do some spring cleaning and simply error on:
>
> * broken tar versions
> * too old versions of git
> * python < 2.7.3
>
> The python version check would move to the oe-init-build-env script, the
> git/tar versions to sanity.bbclass.

Can we also add the python check to bitbake as well?  My concern is not everyone 
uses the oe-init-build-env script, so ensuring that bitbake stops immediately 
and tells the user what's wrong is important.

> The recommendation for anyone with these older versions would be to
> install our standalone tools tarball which would have python 2.7.3 and
> working versions of tar/git.
>
> The reason for the python version change is so we can embrace the
> unittest improvements in 2.7 and drop all of the workarounds for pre
> 2.7.3 bugs in bitbake. This starts to move us towards python 3, if this
> tarball works well, we'd use the same approach to move to python 3.
>
> Any objections?

No objection, this seems fine.  It would be nice if there was a simple way (for 
the tar and git cases) to be able to build them as a user step and then be able 
to use them, but that "nice experience" can easily be handled by documentation 
as well.

--Mark

> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>