I was reviewing some documentation which includes: Redhat for example has a very optimal tool chain which they use for their Enterprise product line and it is not available to other distributions (or rebuilds) and thus their resulting binaries and libraries have been more performant then other Linux distributions we have tested. Can someone say if that's correct? I assumed building was done similarly to koji.

(I could experiment, but it seems better to ask where someone presumably knows, assuming they can say.) _______________________________________________ epel-devel mailing list epel-devel(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraprojec...

On 23 June 2016 at 10:54, Dave Love <d.love(a)liverpool.ac.uk&gt; wrote: > I was reviewing some documentation which includes: > > Redhat for example has a very optimal tool chain which they use for > their Enterprise product line and it is not available to other > distributions (or rebuilds) and thus their resulting binaries and > libraries have been more performant then other Linux distributions we > have tested. > > Can someone say if that's correct? I assumed building was done > similarly to koji. Without a link to the quote you are reading to either get context or to know how relevant it is.. I don't know.

Kevin Fenzi <kevin-+bl/7iUgRMUAvxtiuMwx3w(a)public.gmane.org&gt; writes: > I don't know (I work for Red Hat, but am not directly involved with > internal builds), but I am highly skeptical of the claim. Likewise (currently). > That said, why not ask whoever wrote that doc for some kind of > citation or proof? They say something about testing, so perhaps they > have some proof of this? It was deduced experimentally during early -- for some value of early -- CentOS development. I'll suggest the reference to Red Hat is changed. It could be important to know if it was correct now, which was a reason for asking here. I assume that rebuilds are essentially the same as RHEL (modulo reproducible builds) when it comes to things like reporting bugs and issues relevant to EPEL development. Specifically I assume they won't potentially have different code generation bugs.