With this commit: commit aaf17c251d1161d5a63a197b040235fe1353783c Author: Sam James <sam@gentoo.org> Date: Sat Mar 4 01:19:27 2023 +0000 sys-apps/systemd-utils: add 252.7 Signed-off-by: Sam James <sam@gentoo.org> And an emerge update to update the latest systemd-utils, along with other packages, the second /etc/cron.daily/systemd-tmpfiles-clean ran I had a ton of files under /tmp and /var/tmp get nuked because the latest ebuild is forcibly installing various files in /usr/lib/tmpfiles.d to manage temp directories (amongst other things) without any opt-in into it. This just happened completely transparent to me without any awareness of what the ebuild had setup. I run a system with openrc only and with /etc/conf.d/bootmisc:wipe_tmp="NO". I do not want anything messing with these directories but all it took was for me to do a simple emerge update and I lost a bunch of data (most of it backed up). Granted, important data shouldn't be sitting in /tmp or /var/tmp, and this isn't super important stuff, however it's the principle of things here that's an issue. Pertinent changes of the ebuild diffs related to tmpfiles management: clayne@dorian:/usr/portage/sys-apps/systemd-utils $ sdiff -b -w 180 systemd-utils-251.10-r1.ebuild systemd-utils-252.7.ebuild [..] if use tmpfiles; then if use tmpfiles; then targets+=( targets+=( systemd-tmpfiles.standalone systemd-tmpfiles.standalone man/tmpfiles.d.5 man/tmpfiles.d.5 man/systemd-tmpfiles.8 man/systemd-tmpfiles.8 > tmpfiles.d/{etc,static-nodes-permissions,var}.conf ) ) [..] if use tmpfiles; then if use tmpfiles; then into "${rootprefix:-/}" into "${rootprefix:-/}" newbin systemd-tmpfiles{.standalone,} newbin systemd-tmpfiles{.standalone,} doman man/{systemd-tmpfiles.8,tmpfiles.d.5} doman man/{systemd-tmpfiles.8,tmpfiles.d.5} > insinto /usr/lib/tmpfiles.d > doins tmpfiles.d/{etc,static-nodes-permissions,var}.conf fi fi [..] if use tmpfiles; then if use tmpfiles; then doinitd "${FILESDIR}"/systemd-tmpfiles-setup doinitd "${FILESDIR}"/systemd-tmpfiles-setup doinitd "${FILESDIR}"/systemd-tmpfiles-setup-dev doinitd "${FILESDIR}"/systemd-tmpfiles-setup-dev exeinto /etc/cron.daily exeinto /etc/cron.daily doexe "${FILESDIR}"/systemd-tmpfiles-clean doexe "${FILESDIR}"/systemd-tmpfiles-clean insinto /usr/share/zsh/site-functions insinto /usr/share/zsh/site-functions doins shell-completion/zsh/_systemd-tmpfiles doins shell-completion/zsh/_systemd-tmpfiles > insinto /usr/lib/tmpfiles.d > doins tmpfiles.d/{tmp,x11}.conf > doins "${FILESDIR}"/legacy.conf fi fi Honestly I wouldn't even have this package installed at all if it wasn't necessary. But udev is forcing it on me: clayne@dorian:/usr/portage/sys-apps/systemd-utils $ equery d systemd-utils * These packages depend on systemd-utils: virtual/libudev-232-r7 (!systemd ? sys-apps/systemd-utils[udev,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]) virtual/tmpfiles-0-r3 (!prefix-guest ? sys-apps/systemd-utils[tmpfiles]) virtual/udev-217-r5 (sys-apps/systemd-utils[udev])
It's not that commit, it's that 252 was stabled earlier. Have you followed https://www.gentoo.org/support/news-items/2022-11-21-tmpfiles-clean.html?
And I see now there was a news item on it: clayne@mercury:~ $ sudo eselect news read 18 2022-11-21-tmpfiles-clean Title systemd-tmpfiles --clean enabled by default Author Mike Gilbert <floppym@gentoo.org> Posted 2022-11-21 Revision 1 Starting with sys-apps/systemd-utils-251.8-r1, a script is installed in /etc/cron.daily to run "systemd-tmpfiles --clean" once per day. This will remove stale temp files based on settings specified in tmpfiles.d. This change is meant to mimic the behavior of systemd-tmpfiles-clean.timer from systemd on systems running OpenRC. If you wish to opt-out, simply comment out the command in /etc/cron.daily/systemd-tmpfiles-clean. However, this is the wrong approach IMO. It should *not* be opt-out, it should be *opt-in*. It's a core tenant of how things are done with all of this that data is not unnecessarily deleted, ever, and that there is no violation of the principle of least surprise. Enabling something that will automatically delete data should be something that absolutely requires explicit action as it is new behavior (on the host itself, the approach itself is well known).
