[bitbake-devel] [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote

[Richard Purdie]

On Tue, 2016-08-09 at 18:26 +0200, Olof Johansson wrote:
> On 16-08-09 08:54 -0700, Khem Raj wrote:
> > I am sorry if its coming across this way.I for one was trying to
> > convey
> > that there are reasons to not have such a patch e.g. predictable
> > builds and general support problems with BB_NO_NETWORK.
> > 
> > We have been through this very same problem and decided to use
> > srcrev
> > collection approach which is similar to buildhistory collection
> > approach. It was a bit of getting used to, but in the end it was
> > a very good way.
> 
> Thanks for clarifying, this is a reasonable stance, and I can see
> where you are coming from. But I'm not advocating that this
> behavior should be forced upon anybody. What I'm trying to convey
> is that not all environments have issues with volatile tags, and
> from my pov, it's reasonably easy to fight people (within an
> organization) moving tags if you own the Git infrastructure =).

The trouble is that whilst you and others posting on this mailing list
understand this problem (in some cases now its been explained), in the
general case people don't realise that git tags can be rewritten.

If there is an "easy" option to make a failure go away, people will
take it every time, without understanding why it can be a bad idea.
People prefer not to think if they don't need to.

I've watched git tags get rewritten by upstreams who you'd have thought
would have known better, with all kinds of nasty fallout from the
result as few people understood what happened, why or how to fix it.
The usual "solution" is to blame bitbake or sstate, since they're
complex, people don't understand them and they're therefore clearly at
fault and broken.

So my position on this is based on experience of how badly you can get
burnt by it. I was very reluctant to make bitbake behave in the way it
does today originally but in the end various discussions brought me to
that conclusion.

What I'm trying to avoid in the fetcher is too many code paths. We
already have a lot of them, probably too many, and it makes maintaining
and enhancing the fetchers very very hard as you generally end up
trampling on some weird usecase someone relies upon. I therefore in
general don't like magic switches that drastically alter behaviour,
prefering to have one standard path we all use. Add to that the
concerns above and the idea of making this optional for people makes me
very nervous.

Having better descriptions of revisions is a semi-tangential issue.
There have been a few different approaches to using the output of git
describe or counting revisions and injecting it into PV. The
gitpkgv.bbclass was one similar idea and we did end up putting a method
into the fetcher to better enable this where the revision number was
based on numbers of commits in a branch. I'd be ok with extending or
supplementing that idea to work with git describe so that package
output revisions are human readable. I would however want the recipes
and fetcher to primarily work with the real sha revisions as those are
what define a specific revision in git.

Cheers,

Richard