On Mon, Sep 28, 2026 at 11:26 AM Panu Matilainen via devel <[email protected]> wrote: > > On 9/28/26 12:18 PM, Michael J Gruber wrote: > > Panu Matilainen via devel venit, vidit, dixit 2026-09-28 10:08:45: > >> On 9/22/26 6:32 PM, Neal Gompa wrote: > >>> On Tue, Sep 22, 2026 at 11:08 AM Pavel Raiskup via buildsys > >>> <[email protected]> wrote: > >>>> > >>>> Hi everyone, > >>>> > >>>> We are planning to change Mock's default behavior when building > >>>> packages. Specifically, we intend to unconditionally pass --noclean to > >>>> rpmbuild during builds. This means Mock will no longer execute the > >>>> %clean section of spec files (or the implicit rmbuild cleanup phase). > >>>> So far, Mock has been using --noclean only when > >>>> `cleanup_on_success=False` (opt-in behavior). > >>>> > >>>> Modern RPM packaging guidelines consider the %clean section obsolete. > >>>> Mock already manages the chroot and build root cleanups at the top > >>>> level before and after builds. Running %clean inside the chroot seems > >>>> redundant, and is hard to cover correctly (especially with the new > >>>> "delayed %check" feature). > >>>> > >>>> More context and the background discussion can be found in PR #1809: > >>>> https://github.com/rpm-software-management/mock/pull/1809 > >>>> > >>>> Request for Feedback: > >>>> Before we make this change default in an upcoming release, we would > >>>> like to hear from the community: > >>>> > >>>> Do you have any legitimate use cases where executing the %clean > >>>> section or rmbuild phase inside Mock is still strictly required? > >>>> > >>>> Are you aware of any workflows or tooling built on top of Mock that > >>>> would break if Mock always passes --noclean? > >>>> > >>>> If you have any objections, edge cases, or concerns, or process > >>>> opinions - please let us know. > >>>> > >>> > >>> The %clean section is obsolete because we already define a default > >>> %clean stage in RPM itself since rpm 4.8 in 2009: > >>> https://github.com/rpm-software-management/rpm/commit/3fc58248d23d6f720942e5cbf4f92db246a802f0 > >>> > >>> And modern default %clean handles all the weird multi-buildroot stuff > >>> that is now supported since RPM 4.20. Using --noclean turns all that > >>> stuff off, and can result in broken build results. > >> > >> Huh? > >> > >> --noclean only really affects finished builds because in the other > >> modes, clean steps are not to be executed anyhow. > >> > >> Please be more specific if you have a concrete example where --noclean > >> (inside mock specifically) causes problems. --noclean like any other > >> option of rpmbuild, and if it breaks something then that sounds like a > >> bug to me. > > > > Maybe there's some confusion between the mock option and the rpmbuild > > option here. Also, rpmbuild's man page seems to suggest that `--noclean` > > is not the negation of `--clean`. > > > > If the rpmbuild options are really about executing `%clean` or not after > > the build, then they affect whatever is configured to run there - for > > example, moving something from the build tree to somewhere else that has > > been saved during a multi-stage build, or running whatever over the > > created builds. This may or may not be a "creative" use of %clean, but > > apparently necessary for multilib. > > What on earth? :D > > I get a feeling we mean some entirely different things with multilib > here. Can you point me to an example package that does this mysterious > (to me) multi-stage thing? > > - Panu -
Yeah, there's some misunderstanding, I'm sure. And, uhm, now - when Mock v6.9 is out https://rpm-software-management.github.io/mock/Release-Notes-6.9 .. I realized that we do `--noclean` for years in Koji, since https://github.com/rpm-software-management/mock/commit/638e0abfa05d21171940da734a08b2d4ec497669 .. because Mock by default (when no explicit --resultdir is set) uses `cleanup_on_success=False`: https://github.com/rpm-software-management/mock/blob/3b308660a12fb59886f438a59561f023d01586d8/mock/py/mockbuild/config.py#L670-L672 .. which in turn triggers `rpmbuild --noclean` (=> that's what Koji's been doing). IOW, we should be safe. Sorry for the noise here. Pavel > > > Michael > > > > -- > _______________________________________________ > devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://forge.fedoraproject.org/infra/tickets/issues/new -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
