We are looking for an upstream repository location, ie) a git repository or a mercurial repository, subversion, etc. Anitya reports a ‘homepage’, and PURL provides maps to other upstream sources such as pypi, crates.io, etc. Source0 provides links to tarball downloads but that also is not an upstream repository.
An argument could be made that we should modify Anitya to report the repository in the homepage field. I’m still not entirely convinced that is the right thing to do.
I will point out this definition from rpm.org - RPM Tags for the VCS field:
(Public) upstream source code VCS location. Format : with being the VCS command used (e.g. git, svn, hg, …) and being the location of the repository as used by the VCS tool to clone/checkout the repository (e.g. GitHub - rpm-software-management/rpm: The RPM package manager · GitHub ).
This information allows us to properly provide not only the location of the repository, but the command used and importantly the branch used to generate a tarball.
FWIW: I do not believe there is a direct benefit to a fedora packager. The benefit of doing this is that users and developers can better track upstream and better track upstream fixes. Users (not packagers) will be able to find the upstream repository location and if inclined report a bug, offer a fix, etc. This only encourages the use of open source. Right now this information is obfuscated in the Source0, Anitya, and PURL fields.
AFAICT, ‘rpm -q --qf “%{VCS}\n”’ will show the correct VCS data (if populated). dnf does not yet support queries on VCS.
As for the effort … An initial attempt was done in the hummingbird project to map across a little over 400 packages using a combination of AI and human review. This work was performed months ago and an ~1% error rate was noted using AI. Given that newer models are better at this work I believe the error rate would be below 1%.
There are two ways to go about this and it depends on the answer to “what is an acceptable error rate?”
If we aim for a 0% error rate then we would automate the opening of bugzillas and MRs across the fedora ecosystem. As someone pointed out this may cause a large amount of work for Fedora maintainers.
If we are okay with an occasional error AT THE BEGINNING OF THIS PROCESS, then I would argue that a provenpackager could make this change using by modifying the AI tooling written for the Hummingbird project. Bluntly, we’re going to make mistakes – and those mistakes will have to be fixed by maintainers or by future MRs submitted by other developers.
Ok, I have cleaned up my analysis a little and am working on upstreaming the code that generated these graphs into CHAOSS in this PR.
Here is the current “hierarchy” of upstream url data in the currently available fields in fedora rawhide packages, going from least effort to use to most:
There’s currently 79 packages VCS URLs populated and valid according to the format defined in the RPM spec
There’s currently 30 packages (109 for all steps combined so far) with VCS URLs populated and able to be programmatically corrected to the valid format (i.e. just a bare github link without the git: prefix. This could be a good opportunity to introduce some better validation on this field after these records are updated)
URL
Overall, adoption of the URL field is quite high (only 70 packages dont have it).
~8k packages (~34% of all packages with a URL) have a link (or macro suggesting a link) to a known forge in the URL field, so these values could be copied into the VCS field with 100% confidence that they are no less valid than the value that was being maintained in the URL field before
Theres a further ~8k fedora packages that provide a url (or macro suggesting a url) to a known package repository (pypi, crates.io etc) in the URL. With some extra API calls, these urls may resolvable to an upstream url
theres a further ~830 packages using the gourl macro to populate their URLs. My looking through a small number of these specfiles didnt reveal an obvious URL i could find, but maybe that macro is set outside the individual specfile
~ 85 packages with custom git: urls that could potentially be copied straight over
All of the above urls, when copied over to the VCS field could probably use validation (i.e. make sure the repo wasnt renamed/redirecting, still exists, etc)
Roughly all the URL field values that remain (~30% of fedora packages), are some flavor of “difficult to get to” at scale without use of LLMs and tokens. This includes:
~2600 packages with urls that list a domain (with no paths) as their URL
~2300 packages with urls that are yet to be categorized/dont apply to enough packages (i.e. miscellaneous URLS and the long tail of packages with unique URLs/domains)
~1100 packages with urls that are linking to known docs or project pages
~185 packages with URLs that link to known storefronts (extension stores etc)
~350 remaining packages in tiny categories (FTP links, empty URL values, known wikis/docs, likely dead links[1], etc)
I suspect this set of packages could be where reusing the AI skill from hummingbird to look online for package upstream URLs could have the greatest value.
I could probably continue down this path and do further analysis on how many urls in the URL and VCS fields need updating (because repos have moved, links have broken, etc), but I want to pause here and ask:
Does anyone see any parts of this plan that could/should be acted on now? IMO some good candidates include:
cleaning up the existing VCS values and implementing automatic checks to enforce the already-defined format
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.
Populating the VCS field in the cases where the URL field already links to a known git forge
Open to thoughts on how to approach this without annoying packagers too much.
The checking for dead links was not comprehensive, this is mostly for whole domains/categories that i found to not work ↩︎
The usage of macros in specfile fields is pretty standard and shouldn’t be an issue. You can use rpmspec to parse specfiles[1] and get the value of the expanded value of the VCS tag: rpmspec -q --qf "%{VCS}\n" . If VCS is not set, you’ll get (none) as output. You can also query locally installed packages using rpm -q as Prarit pointed out.
If you do want to implement this in Fedora, there’s a couple steps to this:
Update the Packaging Guidelines to say that the VCS tag SHOULD be used in Fedora packages. (It could be a MUST requirement, but that would make basically the entire Fedora packaging collection strictly non-compliant, so meh). This change would need to be approved by the Fedora Packaging Committee. It would probably be good to bring this up on the devel list too since that’s where most packaging-related discussion actually happens.
Consider adding a CI check to validate the field and warn if it doesn’t exist or is invalid. Maybe this could be done in rpmlint so we don’t need to implement another tool. RPM upstream may be willing to make validation stricter in a feature release.
Consider mass package changes to update existing specfiles. This would probably need a Change Proposal and/or separate FESCo approval. You’d need a provenpackager member (or maybe Release Engineering) willing to run a script to make the Changes (unless you’re going the PR route, but that’d obviously be noisier for packagers).
As for doing a mass package change using AI to populate the VCS field, I think that’d be a hard no, for multiple reasons. I don’t think this metadata is useful if it’s not nearly 100% accurate. Garbage in, garbage out — we don’t want to add bad metadata. I certainly wouldn’t give my git creds to an AI agent to go wild on the Fedora package collection. And I don’t think pushing AI-authored changes without human review is allowed by our policies either.
It’d be best to have an easy-to-audit script that uses objective data (like the value of URL, %forgeurl, Source0, or language package registry metadata) to figure out the VCS URL and patches specfiles to add the tag. In the past, people have created before and after patches so the changes that the script would make can be reviewed before they are automatically pushed.
As for a new VCSBranch tag, I’m not sure upstream RPM would be in favor of that, and I’m mostly fine with standardizing a way to specify VCS URLs, but I’d really prefer not to introduce two new required tags. I’m also less certain on the utility of recording the branch name. Upstream branch names can change and are not something that packagers really keep track of at all. We generally package a specific git tag.
make sure not to run this on untrusted inputs, though. parsing rpm specs can run arbitrary code. ↩︎
Yeah, the main reason my analysis doesnt do this is that it was causing it to take a really long time (the python package i was using to wrap the rpm commands was somehow set to download the patch files and things, and i couldnt figure out how to turn that off. maybe this is something different, but at this stage its mainly exploratory data.
oh yeah there 100% needs to be a human between any AI system and the metadata actually getting in. This is how hummingbird did it and how I’d ideally like to do it too (i.e. if an AI is used to make a guess at package upstream URLs/search for them online when theres no better data source). This way the AI could produce a CSV file that someone can scroll through and check, or that can be broken up into 100 package chunks and spread out (either over time or over multiple people so that every value passes through a person and can be 100% reliable/checked without making one person go through 20,000 URLs in a short time).
That also leads me to another related question:
I have been able to filter the list of values in the URL field down to just places where there is a well formatted github URL in the package, but I’m lacking the experience to know how the data got to be in the URL field to begin with. What im getting at is whether this data is reliable/accurate/whether Fedora packaging already has processes in place to ensure that this value is up to date etc. Can someone (ideally a fedora packager) give me a general sense of the reliability of the existing URL field (beyond just it being a wild west string value). In other words, are there any guarantees that the string value provided it at least related to the package it goes with in some way?
If this URL is a reliable data source, we could easily copy the value from the this field for packages where this URL points to a known forge (and prefix the relevant git: header to the url to be compliant).
Right, you should be able to just call rpmspec in a subprocess. I’d say in most cases where VCS is constructed based on a macro, we’d want to keep it that way, since it avoids duplication in the specfile. And the same for any VCS tags we add — VCS: git:%{url} is probably better than repeating the verbatim value a second time if %{url} is already a link to the forge.
In that case, I’d rather have nothing and rely on packagers to do it manually. I don’t want our package metadata to be filled with AI guesses. The existing sources I mentioned should be pretty reliable in most cases.
I’d say it’s usually pretty reliable. Especially if Source is constructed using %{url} (e.g., %{url}/archive/%{version}/%{name}-%{version}.tar.gz), since that means the package source is also downloaded from the same repo. As far as I know, there’s no other processes in place, but it should at least be checked as part of the initial package review.
I’m not sure why “branch” is suddenly being considered here now? To me this would seem to pollute the “location” type of information with “version” type of information.
It sounds like having a branch name is important to some packages (Hummingbird discovered this with their metadata, and prarit mentioned some example packages in the PR).
Earlier i was wondering if a separate, optional, VCSBranch tag to complement the existing VCS one (so that packages that need it can use it, and most can ignore it). but it seems like thats less likely to happen upstream
@prarit id be interested to understand more about the branch specification usecase as well.
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?)
These all sound like things that would require information to be duplicated in multiple places, or having to be updated manually alongside the package Version - neither of which are great, and would probably count as a negative point against standardization in Fedora.
I would be interested in what use case actually prompted the proposed addition of “branch” information here. For example, I don’t understand the Python example - where the branch can just be determined from the Version itself, without having to set that information in multiple places.
I think its mainly an attempt to find common ground with other usecases (such as the packaging and security work Prarit is doing with hummingbird) that also relies on having a reliable upstream URL.
It sounds like from this thread that there are concerns about the value of improving the quality of upstream URL metadata/improving the population of the VCS tag, so I’m open to other usecases/voices that could also benefit from better metadata linking to upstream URL’s.
Should I move that Pr link to a separate discussion thread?
Discussing “branch” information separately might be a good idea. I feel like it’s muddying the waters here, since it sounds like making the VCS field contain useful information is otherwise largely controversial.
Fedora contains versioned packages for python (python3.14, python3.13, etc.), nodejs (nodejs26, nodejs25, etc.) and others including ruby and go. These are separate and distinct pacakges – the branch location is what makes them different from each other. The branch information is extremely important for information trackers like myself and @moralcode
I’m sorry, but that’s backwards. The thing that makes the packages different is the version. The fact that these versions are developed in parallel in different upstream branches is somewhat orthogonal to that.
I think theres two different usecases here (this became clear to me based on the discussion in the PR filed to the RPM repo).
The VCS tag seems to be specified as an informational field, wheras the Version feeds into functional elements of the build process to correctly label package versions. Reusing the value of Version as a branch specifier only works for projects following that specific branch naming convention. I think keeping these separate allows the VCS field to remain independent as an informational field and serve its purpose of informing people about “where is this software ultimately being developed?”
