Including Upstream Branch information in Fedora Packages

[moralcode (Adrian Edwards)]

This is a spin-off topic from How can we include Upstream URLs in Fedora Packages? addressing specifically the branch information piece.

This is a usecase that i learned about in my conversations with @prarit as it relates to hummingbird packages (hummingbird has defined their own JSON sidecar metadata and is reliably populating upstream url and branch (where needed)

One suggestion in the original thread was

@moralcode

Filing a PR upstream in the RPM Spec definition to potentially propose codifying a VCSBranch tag, or getting the docs for VCS updated with a way to specify the branch name for the packages that need it.

I suspect this is where this PR came from: Add optional branch information to VCS tag by prarit · Pull Request #4235 · rpm-software-management/rpm · GitHub

Id personally like to understand the usecase for branch information more (it isnt the most needed for my own usecase).

@moralcode

For my upstream health metrics usecase, just having the upstream url is fine becuase that usually leads to lots of things like issues, PRs etc (especially since LOTS of packages just use github these days). To me the usecases for branch seem like they could be:

• you are looking for the specific source code that built the package (but maybe thats redundant with Source0)
• as a disambiguator if multiple packages (i.e. different versions of python) use the same upstream URL/are hosted in the same repo (do RPM specs already have a place for something like this, like noting the specific commit from upstream a build is based on?)

Is there a usecase im missing?

Im also curious how some existing concerns play out, such as:

@decathorpe

To me this would seem to pollute the “location” type of information with “version” type of information.

Hope this separate thread helps break out that specific discussion

[moralcode (Adrian Edwards)]

from @prarit in the PR:

I simply want to know where to look/go-to as a developer to report a bug/push a fix. That’s it. That information is hugely beneficial to me as a developer. Having that data in RPMs isn’t necessarily useful to the build but it is useful to me as a human who wants to do the right thing by reporting or fixing a bug.

Seems like the branch name is useful for developers looking for which branch to base their patches on. I can see this having value as an informational field and needing to be a separate field since branch names may not always match the version tag thats used for the actual build

[mjg (Michael J Gruber)]

If by “branch” you mean the git term, then it is mostly useless information. A git branch is a reference which can (and mostly is) rewritten at any time. And without a record of what a branch pointed to at a given point in time (the reflog), this is not verifiable information - just some description of where the packager got things from back then.
Reliable info would be: a commit hash of the commit from which the source tree was taken (or tree hash or tag object hash).