* Kevin Fenzi:
Can packages built in this buildroot be used on the same system with packages from the normal buildroot?
Yes, I expect them to be compatible at the interface level because the flags do not directly alter calling conventions. There could be a slowdown mixing package versions, though.
It's also conceivable t hat some packages change struct layout under #ifdef __AVX2__, and those changes could be externally visible. I do not think this is likely, though, because these packages would fail to run with user-compiled -march=native code today.
I assume one of the reasons to do this is that we don't know which packages benifit from the changes and by how much?
I assumed that machine time and storage is much cheaper than curating the set of packages manually (which potentially requires writing and designing a UI, too).
Do these builds need to be signed?
Why not? If the hash chain through the mirror manager still works or users can go directly to the buildroot repository on https:// URLs, I don't see a strict requirement for that, though.
Would there be some kind of initial 'mass build' to populate existing packages / things that don't rebuild very often?
Yes, for the VZEROUPPER change, we would have to do an initial rebuild.
Would there need to be some kind of bootstrap? Or would this inherit from the existing normal buildroot?
I would just do two rebuild cycles, with GCC and glibc coming first. (That's what I did for the downstream rebuild.) I don't think a real boostrap is needed.
My main concern here is the storage front. Would we need to keep old builds? Or could we just keep the last successfull build only?
I'm not sure. I guess I could keep a copy locally if packages expire really quickly.
I guess ideally there will be 0 changes to spec files (just different macros, etc)? And if there are changes, they would be something we would want to upstream, so perhaps a bugzilla tracker for any spec changes to make sure as much as possible they go upstream and go away?
What do you mean by upstream in this context? Upstream outside Fedora rarely has Fedora-compatible spec files, I think.
Thanks, Florian