On Fri, Jul 31, 2020 at 6:02 AM Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Mark Wielaard wrote:
> Although the sync issues are annoying I do think we, as developers of
> and developers on the Fedora platform benefit from having the annobin
> notes in the binaries. It is like making sure there is unwind
> information or debug packages for each binary.
I am not convinced that this cannot be addressed by my proposed approach of
doing periodic annobin rebuilds in a side tag, only published through Koji
or through some secondary mirror, not in the production repositories. You
have the information you want in those rebuilds then.
I think it does have value, however I think the Red Hat compiler team
drastically underestimated how much breakage we're willing to tolerate
> If things are perfect, they are just there for assurance. But if
> an issue you want to look into, or you get a crash, want to do some
> profiling to see what your machine is doing, writing a new program,
> combine two libraries, etc. you are glad the information is there.
I do not see how the annotations from annobin help in most of those use
cases. In the case of a crash from conflicting flags, the flag conflict can
be debugged by looking at the annotations in the packages from the side tag
proposed above. For profiling, the compiler flags are not really needed. At
most, you may want to document them when publishing results, and you can
also do that from the side tag proposed above.
The thing is, those flags are not going to magically change with every
single package build, and they are also not going to be different if you
rebuild the same SRPM in a side tag containing either the same RPMs or
annobin rebuilds of them (or most likely a mix of both).
That's not true. Since Koji 1.18, it's been possible to modify the
build process by setting simple RPM macros and mock flags in build
tags. And with the module builds (which operate in chain builds on
side tags), there is a higher potential for modifications that can
result in a different set of binaries since it'll generate macros
packages on demand to do complex build environment changes.
真実はいつも一つ！/ Always, there's only one truth!