From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by mail.openembedded.org (Postfix) with ESMTP id 33BF161EEB for ; Fri, 7 Jun 2013 15:26:28 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id r57FQSYs022175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 08:26:28 -0700 (PDT) Received: from msp-dhcp18.wrs.com (172.25.34.18) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.2.342.3; Fri, 7 Jun 2013 08:26:27 -0700 Message-ID: <51B1FBA9.2050005@windriver.com> Date: Fri, 7 Jun 2013 10:26:33 -0500 From: Mark Hatle Organization: Wind River Systems User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Purdie References: <1370602058.6864.24.camel@ted> <51B1F6E1.8050901@windriver.com> <1370617949.6864.43.camel@ted> In-Reply-To: <1370617949.6864.43.camel@ted> Cc: openembedded-core@lists.openembedded.org Subject: Re: OE-Core and Bitbake wrapper changes (min 2.7.3 python version) X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:26:28 -0000 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 6/7/13 10:12 AM, Richard Purdie wrote: > On Fri, 2013-06-07 at 10:06 -0500, Mark Hatle wrote: >> 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. > > We do have checks in there and these will move to the new versions. The > issue we've had before is that you get a syntax error from python trying > to *parse* bin/bitbake. We obviously try and avoid that but it can slip > in for older python versions. > >>> 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. > > "bitbake tar-native-replacement git-native-replacement" will still be > available as things stand but you'd have to put something into the > sanity check to look at the recipes being targeted and skip the sanity > tests. Its complexity I'd prefer not to have and will suck from a > usability perspective since the user would have to remember to do this > each time. The question "can't bitbake do this itself" then comes back > but you really do need a wrapper as there is too much version specific > knowledge. So in summary, I don't want to go here for the rapidly > reducing number of users this affects. Sorry, I wasn't clear. I meant that when it fails, it points the user at documentation that explains how they can build git/tar, etc.. Adding the code to do the build automatically should not be needed. > Cheers, > > Richard > > > > >