On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: >> On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie >> <richard.pur...@linuxfoundation.org> wrote: >> > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >> >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >> >> <ota...@ossystems.com.br> wrote: >> >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <b...@enea.com> wrote: >> >> >> Khem Raj wrote: >> >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >> >> >>> larger in future so I don't think fetching from git will be a good >> >> >>> solution >> >> >>> for gcc ever. >> >> >> >> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB >> >> >> tar.gz when cloned with --depth 1. >> >> > >> >> > I did not check if the fetcher has this support but it would be a >> >> > nice solution. >> >> >> >> Shallow clones won't be able to support SRCREV properly, as you can >> >> only clone shallowly from HEAD, not from an arbitrary point in >> >> history, AFAIK. >> > >> > Right, shallow clones are a can of worms from a variety of angles. >> > >> > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher >> > which: >> > >> > a) Generates tarballs of single git revisions if tarball generation is >> > turned on >> > b) Searches for single revision tarballs before trying the main checkout >> > approach. >> > >> > This would mean that WORKDIR may or may not have a .git directory for >> > any SRC_URI marked with this. I think we should all be able to live with >> > that and it shouldn't break too much? >> >> We'll end with multiple tarballs, aren't we? > > Yes. I'm not seeing that as a big problem for most of the usecases where > we'd use this feature. You could skip shipping the big tarball of the > whole repo at distribution time.
By the way, there're any tool to clean the repo? (as we do for sstate-cache)? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
