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

[Khem Raj]

Olof

> On Aug 9, 2016, at 8:09 AM, Olof Johansson <olof.johansson at axis.com> wrote:
> 
> On 16-08-09 07:34 -0700, Khem Raj wrote:
>> Too literal, I guess a reader is getting what I was referring to
> 
> No, a reader did not understood what you are talking about.
> Quite frankly, you're not being constructive here Khem. Assuming
> that I'm confusing things because we have differences in
> opinions, and that it doesn't matter that I don't understand what
> you are saying as long as you think that other people do is not
> very helpful. What's the point in discussing anything with you?

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.

> 
>> If you were to think of a tool to generate the srcrevs from
>> tags, that IMO can be better solution here. Like Paul
>> suggested.
> 
> Yes, Paul's suggestion was very constructive (thanks!), and
> that's something we might do. But it still forces us to deal with
> sha1 revision ids. Would require effort on our part to hide this
> from our users and automate it somehow. Some issues that we would
> like to handle:
> 
> - changing PV won't have any effect on what source is fetched/used

I believe it should not.

> - changing SRCREV to another revision won't affect PV

If you do not utilize SRCPV in PV variable. SRCREV should not reflect
in the PV

> 
> --
> olofjn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20160809/79ba5edb/attachment-0002.sig>