> -----Original Message----- > From: openembedded-core@lists.openembedded.org <openembedded- > c...@lists.openembedded.org> On Behalf Of Richard Purdie > Sent: den 13 maj 2021 09:09 > To: Andre McCurdy <armccu...@gmail.com>; Alexander Kanavin > <alex.kana...@gmail.com> > Cc: Colin Walters <walt...@verbum.org>; OE-core <openembedded- > c...@lists.openembedded.org> > Subject: Re: [OE-core] master/main branch renaming and bitbake > > On Wed, 2021-05-12 at 17:11 -0700, Andre McCurdy wrote: > > On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin > > <alex.kana...@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... > > I had a look at the code to try and remind myself why it is doing this. > The best answer I found is that it does support filtered fetching of > remotes, i.e. it can and will only pull the branch it wants/needs rather > than a full repo clone. In the case of a small repo, it doesn't matter > much. For a large repo it can make a significant difference to the speed. > We also don't run "test" commands against the remote repo, we figure out > what we want and then get it with small numbers of commands. > > 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? > > 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. > > The fetcher is consistent. It will fail in both cases unless a source > mirror is available with the sources in. If a source mirror is available, > it should work. > > > 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. > > Is explicitly specifying the branch along with the repo url such a big > problem? We already have to provide the url, it isn't like we guess that > too. 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. > Cheers, > > Richard //Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151705): https://lists.openembedded.org/g/openembedded-core/message/151705 Mute This Topic: https://lists.openembedded.org/mt/82782995/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
