Am So., 18. Feb. 2024 um 13:54 Uhr schrieb Miroslav Suchý <msuchy@xxxxxxxxxx>: > > In Copr build system, we noticed that Fedora rawhide chroots can became large and they stay forever as rawhide is never > EOLed. > We plan to work on this soon, but we are not sure what is best approach. I want to ask you - the users of Copr - what > will be convenient for you? > > The problem is described here https://github.com/fedora-copr/copr/issues/2933 > > tl;dr version is: > > * when you build into fedora-39 chroot then the chroot is one day declared as EOLed and if you did not act, then the > chroot from the project is deleted and we reclaim the storage space. > > * when you build into rawhide chroot, then we keep last builds. Even if you do not submit to this project anything for > years, we still keep this chroot. And such chroots can occupy gigabytes of storage. > > > The problem is that builds in the rawhide can be packaged configs, and they can be still usable despite the fact that no > one rebuilds the RPM for years. Or it can be forgotten build that is not even installable in current chroot. We do not > know. And testing installability of package regularly will be expensive task. > > What **you** would find as acceptable policy for pruning rawhide chroots? I see this somehow connected to the discussion about signing keys that we had recently. A radical solution would be: branch rawhide, not from rawhide. So, at the "F40 branch point we had last week", we would: - switch the "alias" rawhide from "meaning f40" to "meaning f41" - rename rawhide chroots to f40 in copr - set up new rawhide chroots ("follow [up] fedora branching") In most cases, "forked" packages in copr are misleading - they are in a chroot without having been built against any version of it. copr users would have to hit "rebuild", which should be OK. Michael -- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
