#2988 closed task (wontfix)
/var/lock should be relative
| Reported by: | Stu | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Book | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
In section 6.5: Creating directories, the LFS manual indicates that /var/lock should be symlinked to /run/lock. I would suggest that the symlink should actually be "../run/lock" (relative instead of absolute), so that it always points to the same location even if it's accessed from outside of the LFS chroot.
Change History (3)
comment:1 by , 13 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:2 by , 13 years ago
Absolute symlinks are categorically bad. This issue isn't about coloring outside the lines, this is about teaching LFS readers correct principles.
You are correct that {LFS}/run/lock does not exist during the LFS creation process, but {HOST}/run/lock might. When chroot-ed or booted into the LFS system the link does indeed point to the correct place. When inspecting the LFS tree from the host system, the link literally points to the host system (because it's absolute). If the link created in the commands in section 6.5 were relative, it would be correct in all contexts.
comment:3 by , 13 years ago
It's never a good idea to make relative symlinks across different file systems.
Bad idea. Within chroot, /run/lock does not exist at all. It is created by the bootscript. Nothing within chroot should use /run/lock as we don't create any daemons. If you are doing something other than LFS in a chroot, you have to create your own environment.