Bugzilla – Bug 1212926
tmpfiles suse.conf conflicts with lockdev.conf
Last modified: 2023-08-15 11:36:23 UTC
/usr/lib/tmpfiles.d/suse.conf:10: Duplicate line for path "/run/lock", ignoring. (26/49) Installing: systemd-253.5-4.1.x86_64 ..................................................[done] /usr/lib/tmpfiles.d/suse.conf:10: Duplicate line for path "/run/lock", ignoring. (27/49) Installing: systemd-network-253.5-4.1.x86_64 ..........................................[done] user@uefi:~> grep -r /run/lock /usr/lib/tmpfiles.d /usr/lib/tmpfiles.d/dmraid.conf:d /run/lock/dmraid 0700 root root - /usr/lib/tmpfiles.d/lvm2.conf:d /run/lock/lvm 0700 root root - /usr/lib/tmpfiles.d/lockdev.conf:d /run/lock 0775 root lock - /usr/lib/tmpfiles.d/lockdev.conf:L /var/lock - - - - ../run/lock /usr/lib/tmpfiles.d/suse.conf:d /run/lock 0775 root root - user@uefi:~> user@uefi:~> rpm -qif /usr/lib/tmpfiles.d/lockdev.conf Name : lockdev Version : 1.0.3_git201003141408 Release : 32.1 I see that lockedv gets dropped (https://bugzilla.opensuse.org/show_bug.cgi?id=1212801) but it does not help users that already have it installed.
Ludwig, it seems that /run/lock shouldn't be defined by lockdev.conf. Maybe it does so for supporting lockdev on systems without systemd but /run/lock is a common location used for other purposes too hence defining it in a "low-level" package, such as filesystem, makes more sense. systemd currently keeps the definition for historical reasons but I think filesystem makes more sense.
we can do that once lockdev is dropped. the fact it's in lockdev now comes from an earlier discussion. the submission was just stuck. Anyway nobody should be using /run/lock really. Those other users are abuse that should use an application specific subdir in /run instead.
lockdev shipping a tmpfiles rule for /run/lock was probably wrong but since this package is in the process of being dropped [1] that should fix the current issue. Reassigning to Ludwig. [1] https://build.opensuse.org/request/show/1098320
lockdev is gone now