Re: [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Wednesday 13 May 2015 10:27:34 ChenQi wrote:
> On 05/13/2015 09:56 AM, Khem Raj wrote:
> >> On May 12, 2015, at 6:45 PM, ChenQi <Qi.Chen@windriver.com> wrote:
> >> 
> >> On 05/13/2015 12:19 AM, Khem Raj wrote:
> >>>> On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen@windriver.com> wrote:
> >>>> 
> >>>> -	install
> >>>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN
> >>>> E_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh
> >>>> ${SDK_OUTPUT}/${SDKPATH} +	# find latest buildtools-tarball and
> >>>> install it
> >>>> +	buildtools_path=`ls -t1
> >>>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN
> >>>> E_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` +	
install
> >>>> $buildtools_path ${SDK_OUTPUT}/${SDKPATH}
> >>> 
> >>> why not create a symink instead of poking using wild chars
> >> 
> >> Because it's simpler.
> > 
> > what happens if I touch an older installer ?
> 
> Hi Khem,
> 
> I make this patch to avoid installing a non-existent buildools-tarball.
> If we touch an old buildtools-tarball, the installation would still
> succeed. The touched one is installed.
> What would lead to a potential problem is the following situation.
> The user built buildtools-tarball, after one day, he modified key part
> of buildtools-tarball recipe, rebuilt it, and then he deliberately
> touched the old one, and then he built an ext SDK.
> I don't think that's a situation we need to take care of.
> But if you insist that we should, you can suggest a reasonable symlink
> name and I would make a new patch.

Honestly I don't see this is as being a problem we need to handle - who is 
going to touch this file during normal usage? Builds failing under the 
conditions described is a much more pressing issue at this point.

It could be that we should re-visit whether using buildtools-tarball rather 
than having its contents be part of the native portion of the SDK is the right 
approach. I'm not sure that we need to do that just at this moment though.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre