[OE-core] OE-Core and Bitbake wrapper changes (min 2.7.3 python version)

Chris Larson clarson at kergoth.com
Fri Jun 7 13:31:14 UTC 2013


On Fri, Jun 7, 2013 at 5:40 AM, Otavio Salvador <otavio at ossystems.com.br>wrote:

>
>
>
> On Fri, Jun 7, 2013 at 7:47 AM, Richard Purdie <
> richard.purdie at linuxfoundation.org> 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.
>>
>> 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?
>>
>
> I fully agree in error on these situations and providing a workaround
> solution for old host systems seems perfect. This would clean a good amount
> of legacy code and I also agree it is the way to go. So count me as a
> supporter for it :)
>

Agreed, I'm in favor as well.
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130607/1cbbba53/attachment-0002.html>


More information about the Openembedded-core mailing list