Re: [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote

[Olof Johansson <olof.johansson@axis.com>]

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 =).

(Having reproducible builds is another way to alleviate the risks
of using possibly volatile tags. If the build output is
different, then the input obviously is different as well (incl.
implicit inputs like datetime, TZ or locale). Just putting it out
there. People in the Debian community and elsewhere are doing a
lot of work in this area. [1])

> >> 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.

Yes, that's the heart of our disagreement, I think. We currently
set SRCREV = "${PV}". We believe that in our environment, we are
safe to do this even without syncing with the remote.

> > - 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

Exactly, so that's the problem for me. I'm hesitent to introduce
sha1s into the metadata in our layers as it will make us have two
variables to keep track of the version. I fear that they will
become out of sync.

If somebody tries to only update the SRCREV, the package
manifests and elsewhere will be confusing for people trying to
troubleshoot as the PV is that of the old version (the same way a
moved tag can cause massive confusion). If somebody tries to only
update the PV, the package manifest will look correct, but the
sources is that of something else. Is this something you have any
experience with?

-- 
olofjn

1: https://reproducible-builds.org/