severity 1053677 normal thanks El 9/10/23 a las 0:34, Diederik de Haas escribió:
I did initially wonder to which package to file the bug against as next to debootstrap I also considered to file it against aptitude. But as the base-files package creates the symlink, I think it's therefor also its responsibility to make sure it points to an existing directory.
I see your point, but the directory /run/lock is special, because directory /run is usually a ramdisk. The base-files package may not be responsible for creating it, because it would not survive a reboot. According to Bug #1039979 (where I'm asked to make such symlink relative, which I can't for now because it's against policy) such directory is re-created by systemd if you accidentally remove it, but it's considered "legacy". This is a snippet from /usr/lib/tmpfiles.d/legacy.conf: ---------------------------------------------------------------------- # These files are considered legacy and are unnecessary on legacy-free # systems. L /var/lock - - - - ../run/lock L /var/log/README - - - - ../../usr/share/doc/systemd/README.logs ---------------------------------------------------------------------- This suggests to me that any program trying to use /var/lock directly instead of /run/lock is probably buggy and should be fixed. Therefore I think you should report this (as a different bug) against any package trying to use /var/lock directly. As I said, I don't think we can make base-files responsible for the existence of /run/lock. If this is a bug at all in base-files, it would be to remove /var/lock altogether, but that's something I would have to coordinate with systemd maintainers. I'm going to keep this open for now until we know if we can do that or not. Thanks.
