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 <[email protected]> Sent: Thursday, March 21, 2019 8:33 AM To: Jaewon Lee <[email protected]> Cc: Manjukumar Harthikote Matha <[email protected]>; [email protected] Subject: Re: [meta-xilinx] [PATCH] xsct-tarball: use fetcher cache > On Mar 20, 2019, at 14:34, Jaewon Lee <[email protected]> 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! -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
