[bitbake-devel] [PATCH] fetch2/git: always use premirror first if update is required

Richard Purdie richard.purdie at linuxfoundation.org
Thu Sep 22 10:17:47 UTC 2016


On Thu, 2016-09-22 at 09:45 +0200, Pascal Bach wrote:
> > 
> > > 
> > >     The tarball should only be fetched if the local ud.clonedir
> > > is out of date, this means the revision that is requested via
> > > SRCREV is not in the local repository.
> > >     In the case the revision is present the tarball should not be
> > > fetched again, at least that was the intention and my local tests
> > > didn't indicate otherwise.
> > > 
> > > 
> > > Yes, but it’s better to run ‘git fetch’ in an out of date clone
> > > than to re-download a 1gb mirror tarball which may well be out of
> > > date too.
> > Agreed, but this doesn't work in the case where the machine doesn't
> > have access to the upstream git repository. For example in the case
> > where BB_ALLOWED_NETWORKS = "*.my.company". The fetcher would still
> > got to to github.com which is not allowed, in that case it should
> > fall back to fetch the tarball from "mirror.my.company".
> > 
> > I'm open for suggestions how to make this more efficient.
> Does anyone have a suggestion how this should behave in the ideal
> case? In my opinion if there is an internal mirror defined it should
> always have precedence even if it might be less efficient.

"less efficient" in this case translates a few seconds of git fetch
operation on something like linux-yocto into a hundreds of megabytes
download.

Much as you might not like it, I really don't think we can change the
code as your patch does as it would badly affect standard usage for
many users.

We need to find an alternative which allows your use case to work but
I'm not sure what that is. Much as I hate it, we may just have to have
a setting which you can set which changes the behaviour. If we do that,
I will want to see test cases added for it though as the fetcher code
is a mass of different configurations and its very very difficult to
maintain as it is without yet more different code paths :(.

Cheers,

Richard







More information about the bitbake-devel mailing list