On Mon, Jan 13, 2020 at 5:18 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Mon, Jan 13, 2020 at 10:52:32AM +0100, Florian Weimer wrote: > > * 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. > > ok. That likely means people will mix them, because it's possible. ;) > > > > 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). > > Well, I don't think a UI is needed. We would just set up the new > buildroot to inherit from the normal rawhide one and use 'koji add-pkg' > to add packages to it, then build them in the alternate buildroot. > > Someone would have to curate it indeed, but it would then use a lot less > cpu/storage. But if it's unclear what packages should be added then > thats probibly not worth it. > > > > 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. > > well, signing takes time, more disk space, etc. > Mirrormanager is not used for koji buildroot repos. They are in only one > datacenter and not mirrored anywhere. They are accessable via https. > > > > 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. > > ok. > > > > 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. > > Well, it's a balancing act for sure... how often do you want to go back > to the 50th previous build? or one from months ago? > Since everything is in git, in theory even a deleted build you could > just rebuild again if needed. Keeping say only the last 3 builds for > each package could save a lot of storage. While on one hand we don't need a long-term storage for development builds, on the other: it is quite valuable to be able to compare the latest successful build with some previous ones to see if we actually improve anything over time. I am thinking on relying on ODCS composes to implement this part. If we setup ODCS pipeline and regularly build composes out of the current content of the Koji tag, then we can store them elsewhere and use as checkpoints: everything which has landed in such a compose can be removed from Koji as soon as it is not used by the buildroot, i.e. it is not the latest build for the component. Then we can implement a separate retention policy for composes which may be more flexible. For example it may rely on whether or not this compose was used in some advanced testing by anyone. > > > > > 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. > > I mean say a package builds fine in normal rawhide, but fails to build > in this new alternate buildroot. You might apply a patch to the package > in the spec conditional on the new dist tag. That patch should go > upstream right? So it works with both normal rawhide and the new flags? > > kevin > _______________________________________________ > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
