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

From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>,
	Andre McCurdy <armccurdy@gmail.com>,
	Alexander Kanavin <alex.kanavin@gmail.com>
Cc: Colin Walters <walters@verbum.org>,
	OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] master/main branch renaming and bitbake
Date: Thu, 13 May 2021 21:12:21 +0100	[thread overview]
Message-ID: <666de7863911bf856d4d9ef8bf939a24813ee913.camel@linuxfoundation.org> (raw)
In-Reply-To: <a1351cd03b2f45c6930ec9e7ef0f7d35@XBOX03.axis.com>

On Thu, 2021-05-13 at 14:25 +0000, Peter Kjellerstedt wrote:
> > Another reason we have the branch name is so that we can ls-remote the
> > repo
> > when using AUTOREV for SRCREV. We've tried to make it so that once a url
> > is established in SRC_URI, you can make it use AUTOREV without changes to
> > the url itself. The AUTOREV code path is in parsing which does mean we
> > need to be efficient about the revision resolution.
> 
> Wouldn't using "HEAD" instead still maintain the same properties as using 
> "master", but with the added benefit that it just works for repositories 
> that decide to use some other branch than "master" as their main branch?
> E.g., using `git clone --single-branch` (without -b) fetches HEAD and 
> whatever branch it references, which is what we want, is it not?
> > 

See the ;usehead=1 uri option.

> > 
> One problem I have with the way the branch is specified is that it is a 
> URL parameter. This means that when I want to add a bbappend to specify 
> another SRCREV, it becomes problematic if that SRCREV is on a different 
> branch than what the base recipe uses. It basically means one has to 
> use SRC_URI_remove to remove the original URL for the repository, and 
> then add a new version of the URL with SRC_URI_prepend. This obviously 
> is unrelated to the discussion about main vs. master, but I would very 
> much like to see a new variable, e.g., SRC_BRANCH, being added to 
> complement SRCREV. There is an edge case for recipes that use multiple 
> Git URLs in the SRC_URI, but they are rare, so having to specify the 
> branch using the branch= parameter in the unlikely event that those 
> repositories need different branches should be acceptable.

This is getting a little sidetracked from the original discussion. I believe
anyone changing branch urls like that can probably parameterise the url
themselves and there isn't generic demand to add more complexity...

What I do suspect we need is the ability to change url parameters in 
mirroring url mappings, which could possibly help for a few of these 
cases too. There is an open bug for that, I keep meaning to try and sort
it out.

Cheers,

Richard