On Fri, Feb 5, 2021 at 7:03 AM Marek Marczykowski-Górecki marmarek@invisiblethingslab.com wrote:
On Thu, Feb 04, 2021 at 10:56:43PM -0500, Neal Gompa wrote:
On Thu, Feb 4, 2021 at 9:23 PM Kevin Fenzi kevin@scrye.com wrote:
On Fri, Feb 05, 2021 at 12:17:28AM +0100, Marek Marczykowski-Górecki wrote:
Does it make sense?
That does make sense to me... and perhaps this fits in with that we generate debuginfo/debugsource rpms when we build something. We just expand things to also produce a buildinfo subpackage (of course then we need tools to gather them/put them in a repo/allow users to install them, etc).
Can you expand on that last part? Are you referring to some automation that pulls debuginfo rpms into a separate repository? I guess the buildinfo one should go into sources repo, right?
Then, you could 'dnf install foobar-buildinfo-1.0-1.fc35' and possibly there could be tools that would read that .buildinfo and feed the src.rpm into mock or whatever with that input?
That is, of course, another valid strategy, and may make sense given the archful nature of some things.
New sub-package sounds like a good idea. Is it ok to package it as a single file in /usr/src/buildinfo?
Sure, we'd probably have buildinfo packages in a separate repository like we do debuginfo packages. Most people will never use them.
The advantage of -buildinfo packages is that we can start with a buildinfo file and actually add more as we want to have more complete build records, including macros, environment variables, etc.
-- 真実はいつも一つ!/ Always, there's only one truth!