* 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
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
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
I guess ideally there will be 0 changes to spec files (just
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.