RFE: provide a mecanism to store buildroot composition in the srpm or a specific subpackage

[nim-nim]

Some rpm consumers would like to analyse what deps were used to produce a particular package.
gofed/go-macros#2

Right now this is logged by tools like koji (because only the buildsystem knows what it put in the buildroot), but having to access those tools post-build is far from ideal. It would be much nicer if there was a mecanism for the buildsystem to handover this info to rpmbuild and get it stored in the srpm or a specific rpm subpackage

[jnpkrn]

Like in -debuginfo, where it might further help in case of unannounced
ABI breaks?

I see the value of this also for other things, e.g., witnessed daisy
chained breakages because of particular subtle change in linker's
behaviour, thought this is covered with annotations in ELF notes
these days, can only see the compiler's version, though.

[ignatenkobrain]

I don't think that this should be job of RPM. With koji you can always say what packages were available at the time of build, do dependency resolution and voila.

[ignatenkobrain]

I think you need to use some kind of Provides: bundled() and put there whatever was used in buildroot. Doing this somewhere else doesn't worth it.

[nim-nim]

The people who asked this just wanted to access the info computed by koji (or mock or copr) in the produced rpm files, without needing to connect to koji (or mock or copr)

Not to mention, than mock and copr do not archive all build roots they are cleaned up regularly, the only thing that remais are the produced packages

[nim-nim]

And it's not about "bundling". The build root assembled by the build system is not "bundling".

[ignatenkobrain]

yes, but you know that SRPM is built in one environment while rest of packages in others.

[ignatenkobrain]

and if you want to go with subpackage, you don't need any changes in RPM. Just override %build/%install (whatever is generating debuginfo subpackages) and run rpm -qa there. Although in some cases it won't work. This should be done by mock, really.

[nim-nim]

Sure, computing the list needs to be done by the build system, since it's the system that actually assembles the build root. But the build system needs a way to store the resulting list in one of the produced rpm files, since ultimately only those files are lept long-term.

Unless I'm missing something, storing into the produced rpm files needs an entry point in rpm? How can the cbuild system handover the information to rpmbuild so that it's reasonably transparent to the packager and reliable?

[nim-nim]

It turns out that even an historic package like elfutils has to hack this in %check because it's not done by default.

[rpm-maint]

On Wed, May 01, 2019 at 12:56:39AM -0700, nim-nim wrote: It turns out that even an historic package like elfutils has to hack this in `%check` because it's not done by default.

I was wondering what this was referring to and I think you mean: %check # Record some build root versions in build.log uname -r; rpm -q glibc It is indeed useful to know the kernel (and glibc) version that the elfutils testsuite is been run against. Especially since it contains various testcases for core dumps as produced by the kernel, which contain CFI as produced by the glibc version.