<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 7, 2013 at 7:47 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Its not secret that I hate the current bitbake wrapper script and want<br>
to remove it for 101 different reasons.<br>
<br>
I now have code which removes the need for the double execution of<br>
bitbake which was the only fundamental reason we had it. The question<br>
therefore remains, what to do with the other pieces of the wrapper,<br>
specifically the tar and git versions checks.<br>
<br>
As a reminder for those who don't remember the problem here, the git<br>
version is checked since we use certain parameters in the git fetcher<br>
which need certain versions of git and git is in ASSUME_PROVIDED these<br>
days. Its possible to trigger git operations at part time to resolve<br>
revisions. tar is even more ugly since the wrong version has issues<br>
extracting sstate archives. These issues mean injecting building them<br>
into the dependency chain at the right point is hard.<br>
<br>
Personally, I think we carry around a bit too much legacy these days and<br>
its starting to hurt us. I would therefore like to propose that we take<br>
this opportunity to do some spring cleaning and simply error on:<br>
<br>
* broken tar versions<br>
* too old versions of git<br>
* python < 2.7.3<br>
<br>
The python version check would move to the oe-init-build-env script, the<br>
git/tar versions to sanity.bbclass.<br>
<br>
The recommendation for anyone with these older versions would be to<br>
install our standalone tools tarball which would have python 2.7.3 and<br>
working versions of tar/git.<br>
<br>
The reason for the python version change is so we can embrace the<br>
unittest improvements in 2.7 and drop all of the workarounds for pre<br>
2.7.3 bugs in bitbake. This starts to move us towards python 3, if this<br>
tarball works well, we'd use the same approach to move to python 3.<br>
<br>
Any objections?<br></blockquote><div><br></div><div style>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 :) </div>
</div><div><br></div>-- <br>Otavio Salvador O.S. Systems<br><a href="http://www.ossystems.com.br" target="_blank">http://www.ossystems.com.br</a> <a href="http://projetos.ossystems.com.br" target="_blank">http://projetos.ossystems.com.br</a><br>
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750<br>
</div></div>