* 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 _______________________________________________ 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
