coreos/go-systemd

Branch rename from "master" to "main" breaks every Yocto build using go

JanneKiiskila opened this issue · 7 comments

JanneKiiskila commented

PR #370 breaks every single Yocto build in the whole wide world that uses go.

  • Reason being that most Yocto recipes specify the SRC_URI with a hash and then as there is no branch specifier it goes and does an additional check if the hash is on the branch it assumes.
  • It then goes on assuming the default branch to be master.
  • Which in this case has stopped to exist, as it was renamed.

This is causing massive issues to a lot of Yocto builds around the world and we would greatly appreciate, if you could create a branch called master back to it (and it should point to the same hash it used to point before the rename).

  • It can be deprecated.
  • You can do all your activities on main as you wish.
  • It just needs to exist.

The updated recipes will be compliant with the main branch, but it will take time and we cannot easily fix existing releases that rely on this.

Please?

bgilbert commented

I've re-pushed the master branch, with a commit on top that removes all contents and refers developers back to main.

I have a couple requests for you, though:

  1. Could you give us an estimate of how long before master can be removed without breaking Yocto users?

  2. Could you please link to (or file) a bug report for this behavior in Bitbake? Upstream projects are going to continue to rename their default branches, and it's not reasonable to go around asking them to put their old branches back because some tool doesn't know how to query a repo for its default branch.

xref: ostreedev/ostree#2360

  • 👍1
  • ❤️1
rpurdie commented

Speaking as a Yocto Project developer who was pointed at this issue and who maintains bitbake, the advice is to add ;branch=main to the SRC_URI url in any recipe that is affected by a change like this. We have a long history of being very specific about the sources we build requiring specific git hashes or tarball checksums and specifying the branch name isn't any different.

We did already ensure that if you have a source mirror, it will persist branches that were deleted upstream inside our source mirrors so the old names would work with those as well as the new. If you didn't mirror the sources, that is unfortunate. We do have mirrors for the core YP components.

Even if we did (or do) make bitbake know about the default from the upstream repo, far too many other things would remain broken (e.g. EOL YP releases) and it would significantly complicate the source mirroring and fetcher code so updating the SRC_URI really is easier.

bgilbert commented

@rpurdie Thanks for your reply; I really appreciate it.

That's a perfectly fine downstream policy if YP and its community are willing to bear the burden of it. Please do note what happened here, though: a downstream recipe made an assumption about upstream's long-term intentions, and then upstream was urgently asked to provide a workaround when that assumption turned out to be incorrect. The same thing happened in ostreedev/ostree#2360, and I don't know whether to expect more such requests; we renamed the master branches in 17 projects yesterday.

Is there anything YP can do, in terms of docs or messaging, to help its community better prepare for these sorts of changes in other projects? Branch renaming will be pretty common for a while, I'd think, as upstreams move toward using more inclusive language in their codebases. It'd be good to avoid inadvertently imposing extra constraints on projects that decide to make that change.

JanneKiiskila commented

The only sensible thing I can think of (which helps to branch renames) is that:

  • bitbake is given a global option to stop checking for the branch name, if the branch name is not given OR
  • bitbake is given more logic for the definition of default branch, ie. it can be either master or main.

I've understood the code fetching logic is already quite complicated, so simplest would be to remove the whole branch check. What value does it really add, if the hash is already matching? Git hashes are unique enough.

JanneKiiskila commented
  1. Could you give us an estimate of how long before master can be removed without breaking Yocto users?

You really can't remove it ever. There have been numerous releases that have already been created and all those old releases essentially get broken (unless those releases have also stored their full DL_DIR, which is not the case for all of those for sure).

bgilbert commented

It turns out that BitBake allows users to override the SRC_URI for a BitBake recipe, for example via a .bbappend file. The Yocto project architect has advised us that this is a routine procedure when an upstream renames a branch.

Since it appears that the removal of the master branch will not have unavoidable long-term consequences for downstream Yocto users, we plan to remove the master branch again on June 15. If your builds are affected by this change, please update your recipes or local configs and help spread the word to others who might also be affected.

bgilbert commented

The master branch has now been removed again. Thanks for bringing this issue to our attention.