On Thursday, December 17, 2020 9:04:42 PM CET Kevin Fenzi wrote: > On Thu, Dec 17, 2020 at 10:17:45AM +0100, Pavel Raiskup wrote: > > On Wednesday, December 16, 2020 8:25:50 PM CET Kevin Fenzi wrote: > > > On Tue, Dec 15, 2020 at 10:54:07AM +0100, Miroslav Suchý wrote: > > > > https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap > > > > which is still fresh feature - just one year old :) And so far not enabled in Koji. > > > > > > > > When *this* will be enabled in Koji, we can finally boost the RPM > > > > development to levels previously unimaginable. :) > > > > > > Yeah, we should discuss how to manage and land this. Ideally there would > > > be a lot of CI/QA/Gating on the image, and we would have easy ways to > > > roll back to a known good one in case. > > > > Sounds good! Likely we'd need an image for each chroot and arch. Where > > can we start? :) > > Still a lot of things to ponder here... > > I think it would be important to maintain the ability for users to build > things locally with mock and have them 'close' to what it is in koji. > That would I guess involve publishing all the bootstrap images and > getting mock to be able to download the right ones for the branch/arch. Having it published would be nice. OTOH even now the local mock build is far from what is done in Koji (as far as --enablerepo=local isn't used). And bootstrap can "only" affect the target buildroot installation transactions. > CI/Gating/testing on the container(s). Dnf/RPM should be tested, since that's the only thing used there. > Way for releng to go back to older container(s). > > Way for releng to go to newer/force regeneration of container(s). Sure, as symlink to the latest build repo exists, there could be the 'latest' image tag? > koji adjustments: way to record whats in the container/what container it was. > What does it mean for koji's srpm groups? I guess not much? The groups should be installed to build chroot from bootstrap chroot. > What does this mean for reproducability? Do we keep all containers ever used > for bootstrap so we can duplucate builds? Do we just keep a way to recreate > them? This should normally bring a really low amount of non-determinism, because mock only uses the DNF and RPM (and it's deps) from the bootstrap. How long back could we get if we wanted to restore some random Koji builder state from the past, namely to get the installed host dnf/rpm stack that was used for a concrete build? > Could we just re-use the fedora minimal container? I guess not, but it > would be nice if we could. I'm not sure, is the 'fedora:33' the minimal one? That is used now. But it would be good if 'dnf-plugins-core' was present ... so we could build a thin layer on top of that. > Also, I am guessing this all works with nspawn, we are (still) using old > chroot, we would have to move to nspawn first right? (which we need to do > anyhow). No, fortunately this has nothing to do with nspawn. The --use-bootstrap-image is yet another way to prepopulate bootstrap chroot contents -- and mock can both do chroot() or call systemd-nspawn instead to execute 'dnf' command inside the bootstrap. > I'm sure I'll think of more. :) Yeah, not a trivial thing. Pavel > 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
