Description of problem: when building rpms and populating the fields, the ${sourcerpm} field is populated, and that corresponding src.rpm has its ${pkgid} field populated, can we please populate the ${sourcepkgid} field to the rpms. Version-Release number of selected component (if applicable): rpm-4.11.3-35.el7.x86_64 and rpm-4.14.2.1-4.fc30.1.x86_64 How reproducible: always missing Steps to Reproduce: 1.rpm -q --queryformat '%{name} %{pkgid} %{sourcepackage} %{sourcerpm} %{sourcepkgid}\n' bash 2. rpm -qp --queryformat '%{name} %{pkgid} %{sourcepackage} %{sourcerpm} %{sourcepkgid}\n' bash-4.2.46-31.el7.src.rpm 3. Actual results: bash ed4d986a9753c79474e6ab726f40d864 (none) bash-4.2.46-31.el7.src.rpm (none) bash b43126f3f818c27557532d67d1a0da01 1 (none) (none) Expected results: bash ed4d986a9753c79474e6ab726f40d864 (none) bash-4.2.46-31.el7.src.rpm b43126f3f818c27557532d67d1a0da01 bash b43126f3f818c27557532d67d1a0da01 1 (none) (none) Additional info:
Rpm only stores the sourcepkgid if the source rpm was built in the same run as the binary (that is, built with -ba), this is by design AFAICT. When -ba is used, the pkgid of the source rpm is inserted to the binaries from that build as the sourcepkgid. When no source package is built, there is no source id to insert. That sourcepkgid is missing is a side-effect of how our build-system(s) work, not something that rpm can help with. One could argue that --rebuild should insert the pkgid of the src.rpm being rebuilt, but that would break the contract of "built in the same run".
On a second thought, koji can't do anything about it either. This is actually working as designed, to the effect that it shows how it was (not) built. Even if mock+koji used -ba to build the resulting package, the resulting (source)pkgid would be specific to that architecture, yet we only ship one src.rpm per package. So it would still be different for all but one (random) architecture. This would call for a different kind of id/hash altogether. Reassigning back to rpm for further consideration as an RFE.
I could see where various architecture binary rpms point to the same `sourcepkgid`. That makes sense, and not a blocker. As for some contract of "built in the same run", this seems a silly contract to hold. If I --rebuild a src.rpm, the resulting rpm should still point to it.
The contract is what it is, made long long time ago and we can't just go change it. The thing is, if --rebuild were to produce an src.rpm, its id would differ from that of the one used to launch the build, because all sorts of timestamps and architecture-specific information is encoded in there. I think the productive way out of this would be to generate a new kind of hash that is actually reproducable (basically, hash of the spec itself + all sources and patches) across different builds, and store that into binaries and sources similarly, but without the requirement of same run.
As explained above, the %{sourcepkgid} tag behavior is not a bug, closing. I opened an upstream ticket to discuss alternative approaches though: https://github.com/rpm-software-management/rpm/issues/957