Re: We have to talk about annobin... again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux