Running todays dnf update I saw:
usr/lib/tmpfiles.d/sddm.conf:6: Line references path below legacy directory /var/run/, updating /var/run/sddm → /run/sddm; please update the tmpfiles.d/ drop-in file accordingly.
Any ideas what this is about?
Thanks, Neal
On 3/8/23 06:45, Neal Becker wrote:
Running todays dnf update I saw:
usr/lib/tmpfiles.d/sddm.conf:6: Line references path below legacy directory /var/run/, updating /var/run/sddm → /run/sddm; please update the tmpfiles.d/ drop-in file accordingly.
Any ideas what this is about?
Hi Neal,
Historically, "/run" was beneath "/var" but has been promoted to its own root level space. At least so far programs still using the historical location continue to run but are advised to change the caller to use /run instead. It's less a warning than an advisement.
It's easy to change the location if it's referred to in something like a systemd .service file because they are text. If it's hard coded it has to be changed by the maintainer or developer.
Mike Wright
On 8 Mar 2023 at 7:05, Mike Wright wrote:
Date sent: Wed, 8 Mar 2023 07:05:34 -0800 Subject: Re: tmpfiles.d/ update with today's update To: Community support for Fedora users users@lists.fedoraproject.org From: Mike Wright nobody@nospam.hostisimo.com Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On 3/8/23 06:45, Neal Becker wrote:
Running todays dnf update I saw:
usr/lib/tmpfiles.d/sddm.conf:6: Line references path below legacy directory /var/run/, updating /var/run/sddm → /run/sddm; please update the tmpfiles.d/ drop-in file accordingly.
Any ideas what this is about?
Hi Neal,
Historically, "/run" was beneath "/var" but has been promoted to its own root level space. At least so far programs still using the historical location continue to run but are advised to change the caller to use /run instead. It's less a warning than an advisement.
It's easy to change the location if it's referred to in something like a systemd .service file because they are text. If it's hard coded it has to be changed by the maintainer or developer.
I had seen same message on a machine, and made change to file a number of times, but then did dnf reinstall sddm to see if it would fix the messages, but then checked file again, and it was back to /var/run.
Mike Wright _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On Wed, 2023-03-08 at 07:05 -0800, Mike Wright wrote:
Historically, "/run" was beneath "/var" but has been promoted to its own root level space. At least so far programs still using the historical location continue to run but are advised to change the caller to use /run instead. It's less a warning than an advisement.
So... my take on it would be that they're trying to put the notion into the heads of people working on the software, rather than trying to get end-users to change their systems?
I'd imagine if the average user went tweaking their system as advised, the next package update is probably going to undo it.
On Wednesday, 8 March 2023 14:45:04 GMT Neal Becker wrote:
Running todays dnf update I saw:
usr/lib/tmpfiles.d/sddm.conf:6: Line references path below legacy directory /var/run/, updating /var/run/sddm → /run/sddm; please update the tmpfiles.d/ drop-in file accordingly.
Any ideas what this is about?
https://bugzilla.redhat.com/show_bug.cgi?id=2176111
It's is fixed and the new sddm-* packages should hit updates/stable pretty soon.
-Colin