Bug 1008387

Summary:	rpm: include source package NEVR in binary package
Product:	[Fedora] Fedora	Reporter:	Florian Weimer <fweimer>
Component:	rpm	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	ffesti, jzeleny, novyjindrich, packaging-team-maint, pmatilai
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Florian Weimer 2013-09-16 09:56:43 UTC

Currently, there is only the more or less free-form SOURCERPM tag that includes the source RPM name.  It would be good to have explicit data on the precise version of the source RPM, including the epoch.  The SHA1HEADER hash of the SRPM would be nice to have, too.

Obviously, these fields would have to be optional (but they should be included for SRPMs as well, if the SRPM isn't actually buildable from itself in a reproducible manner, which I suspect happens in some cases).  But they should be populated automatically during regular package builds.

Comment 1 Panu Matilainen 2019-03-13 09:42:47 UTC

There's a basically reverse RFE of this upstream now: https://github.com/rpm-software-management/rpm/issues/642
Like noted there, if we add one I think we should add the other one too so perhaps there's hope that this will finally move forward...

Comment 2 Florian Weimer 2019-03-13 09:51:53 UTC

(In reply to Panu Matilainen from comment #1)
> There's a basically reverse RFE of this upstream now:
> https://github.com/rpm-software-management/rpm/issues/642
> Like noted there, if we add one I think we should add the other one too so
> perhaps there's hope that this will finally move forward...

I don't think this will work for Fedora because we throw away the source RPMs for all but one architecture, and the subpackage data is inconsistent across architectures and cannot even be computed in a cross build in general.

Comment 3 Panu Matilainen 2019-03-13 10:03:27 UTC

That's no different from all the other build-specific data that is stored in the src.rpm (dependencies, architecture even).

The src.rpm never was arch-independent, and trying to treat it as it were (such as Fedora is doing) just leads to problems. Witness the endless bug reports on builddep using the repository data not working on yum/dnf.

Comment 4 Florian Weimer 2019-03-13 10:13:17 UTC

Understood.  I just question the utility of storing such data in the Fedora context, when we would throw it away anyway.