On Fri, Jul 31, 2020 at 6:02 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> 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 for it. > > If things are perfect, they are just there for assurance. But if there is > > 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! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
