On Fri, Feb 5, 2021 at 7:03 AM Marek Marczykowski-Górecki
<marmarek(a)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(a)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!