Re: [OE-core] master/main branch renaming and bitbake

["Andre McCurdy" <armccurdy@gmail.com>]

On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> And by the way, another reason to check that revision is linked to a branch is when SRCREV is updated - we need some reassurance that the updated SRCREV comes from the same branch as previous SRCREV, or that if the branch has changed, it's explicitly visible in the diff and explained in the commit message.

None of the answers given so far seem very convincing...

If the git revision that a recipe wants is available on an unexpected
branch in the upstream repo then it's not really different from a tar
file being fetched from a mirror rather than whatever is in SRC_URI.
If we want the fetcher to fail as an indication that an upstream git
repo has renamed branches then don't we also want it to fail if a tar
file disappears from an upstream server? It seems odd that one should
be a fatal error and the other to be something we try to cover up and
hide from the end user.

Anyway, for recipes which don't explicitly specify a branch in SRC_URI
it would seem quite reasonable for the fetcher to check what the
default branch is set to in the upstream repo and search for the
required git revision in that branch (rather than rely on a hardcoded
default of "master" as we do now). Going forward, there's going to be
less standardisation on what upstream repos call their default branch,
so we're either going to have to explicitly specify a branch in more
and more recipes or teach the fetcher to automatically figure out what
the default branch in the upstream repo is.

> Alex
>
> On Wed, 12 May 2021 at 23:17, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>>
>> On Wed, 12 May 2021 at 22:44, Colin Walters <walters@verbum.org> wrote:
>>>
>>> On Wed, May 12, 2021, at 4:40 PM, Alexander Kanavin wrote:
>>> > For ostree, yes:
>>> > http://git.openembedded.org/meta-openembedded/log/?h=master-next
>>> >
>>> > For the generic case, no. It's not a good idea to start guessing what
>>> > the upstream did.
>>>
>>> What is the goal of the `branch=` specification?  I can understand it being *informative* for humans specifically when things like non-master/main branches e.g. `release-4.x`, `lts-`, `stable-` etc. are involved.
>>>
>>> But why is bitbake explicitly checking it?  Is it to validate what the human expressed, or is it to try to cover some security aspect?  Something else?
>>
>>
>> To ensure the specified revision is actually linked with the specified branch, and not just free-floating, and catch branch renames, deletions and force pushes. You can override that behaviour with nobranch=1, at your own risk - free-floating revisions can be 'garbage collected'.
>>
>> Yes, it's annoying when the upstream renames branches, but it's no different than upstreams clearing up old tarballs, or disappearing altogether. Ensure you have proper download mirrors.
>>
>> Alex
>
>
> 
>