[meta-xilinx] [PATCH] xsct-tarball: use fetcher cache

[Jaewon Lee]

Patch merged after rebase to sit on top of some checksum changes in xsct-tarball class in 2019.1

-----Original Message-----
From: Jaewon Lee 
Sent: Thursday, March 21, 2019 9:40 AM
To: 'Jean-Francois Dagenais' <jeff.dagenais at gmail.com>
Cc: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>; meta-xilinx at yoctoproject.org
Subject: RE: [meta-xilinx] [PATCH] xsct-tarball: use fetcher cache

Hi Jean,

Ok you are right.
This would be needed for cases where you are using the same build directory for multiple release builds Thanks for the patch

Thanks,
Jaewon

-----Original Message-----
From: Jean-Francois Dagenais <jeff.dagenais at gmail.com>
Sent: Thursday, March 21, 2019 8:33 AM
To: Jaewon Lee <JAEWON at xilinx.com>
Cc: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>; meta-xilinx at yoctoproject.org
Subject: Re: [meta-xilinx] [PATCH] xsct-tarball: use fetcher cache



> On Mar 20, 2019, at 14:34, Jaewon Lee <JAEWON at xilinx.com> wrote:
> 
> Hi Jean,
> 
> Just tested this again,  as long as the tarball is there in downloads, it will not redownload.
> If it starts with a fresh tmp directory, xsct-tarball will reextract to tmp/sysroots-xsct, but will not redownload tarball
> 
> Please check again

If I remember correctly, the problem with disabling the fetcher cache is that it will bypass mirrors as well. Mirrors would typically be LAN local.

In any case, when downloading to the "downloads" folder, it is essential to include version numbers in the target file. Otherwise, when you'll update to 2018.4 for example, fetcher will look in the local downloads folder and consider the "xsct.tar.xz" file as the correct file. Then only your manual xsct-tarbal.bbclass hash will detect the file as incorrect and re-download it, from the original URL.

So if you had 2 build directories, say one using v2018.3 and the other v2018.4, and both build directories pointing to the same download directory (which is common and recommended even), then the builds in each would fight over the common file in downloads/xsct/xsct.tar.xz and constantly overwrite it with the "correct" version.

This is what the "downloadfilename" SRC_URI flag is for. I assumed you had to add the "cache = False" because you had trouble with this. If not, then why would you want to disable the nice cache feature of the bitbake fetcher?

I would strongly recommend applying my patch before you guys release 2018.4! ;)

Cheers!