On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote: > > On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote: > > > Adam, > > > > > > Is there a way already to achieve test isolation during the rpm build? > > > > Nothing systematic that I'm aware of, no. It would be tricky because > > there is no one universal Standard Test System (not even within a > > single language ecosystem, let alone across all of them). Currently > > you'd have to design something unique, if you wanted to implement this > > for your package. > > If we wanted to pursue that, I'd suggest the following: > remount $RPM_BUILD_ROOT read-only for the %check phase > (or maybe overmount it with a writable overlayfs that is thrown > away after %check finishes, and warn if any modifications were made.) > %check is executed after %install, so everything should be in place > before %check, and %check may be skipped, so no modifications to > installed files should be done in %check. > > Considering possible implemention details, machinectl has 'bind' and > 'bind --read-only' that might be useful here. But mock uses > systemd-nspawn in a way that does register the container with machined. > So maybe it'd be more reasonable to just execute a mount command directly > from mock. > > This is independent of the test system and does not require splitting > of the test sources. > Another thing to consider is making RPM unshare each build phase like it can for scriptlets now at install time[1]. Sandboxing and limiting in rpmbuild itself like we can with rpm can also help with this. I believe moss[2]' boulder tool does this. [1]: https://github.com/rpm-software-management/rpm/pull/2666 [2]: https://github.com/serpent-os/moss/tree/main/boulder -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
