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... 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.kana...@gmail.com> > wrote: >> >> On Wed, 12 May 2021 at 22:44, Colin Walters <walt...@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 > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151693): https://lists.openembedded.org/g/openembedded-core/message/151693 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] -=-=-=-=-=-=-=-=-=-=-=-
