[arch-dev-public] general packaging question about symlinks
we have a bugreport to change a relative symlink to an absolute symlink http://bugs.archlinux.org/task/14895. I don't really get the point where there difference will be and if the links would be broken when using different filesystems/partitions and links in itself. I'd like to hear your opinions for a general packaging rule. -Andy from coreutils info page: 12.2 `ln': Make links between files =================================== `ln' makes links between files. By default, it makes hard links; with the `-s' option, it makes symbolic (or "soft") links. Synopses: ln [OPTION]... [-T] TARGET LINKNAME ln [OPTION]... TARGET ln [OPTION]... TARGET... DIRECTORY ln [OPTION]... -t DIRECTORY TARGET... * If two file names are given, `ln' creates a link to the first file from the second. * If one TARGET is given, `ln' creates a link to that file in the current directory. * If the `--target-directory' (`-t') option is given, or failing that if the last file is a directory and the `--no-target-directory' (`-T') option is not given, `ln' creates a link to each TARGET file in the specified directory, using the TARGETs' names. Normally `ln' does not remove existing files. Use the `--force' (`-f') option to remove them unconditionally, the `--interactive' (`-i') option to remove them conditionally, and the `--backup' (`-b') option to rename them. A "hard link" is another name for an existing file; the link and the original are indistinguishable. Technically speaking, they share the same inode, and the inode contains all the information about a file--indeed, it is not incorrect to say that the inode _is_ the file. On all existing implementations, you cannot make a hard link to a directory, and hard links cannot cross file system boundaries. (These restrictions are not mandated by POSIX, however.) "Symbolic links" ("symlinks" for short), on the other hand, are a special file type (which not all kernels support: System V release 3 (and older) systems lack symlinks) in which the link file actually refers to a different file, by name. When most operations (opening, reading, writing, and so on) are passed the symbolic link file, the kernel automatically "dereferences" the link and operates on the target of the link. But some operations (e.g., removing) work on the link file itself, rather than on its target. The owner, group, and mode of a symlink are not significant to file access performed through the link. *Note Symbolic Links: (libc)Symbolic Links. Symbolic links can contain arbitrary strings; a "dangling symlink" occurs when the string in the symlink does not resolve to a file. There are no restrictions against creating dangling symbolic links. There are trade-offs to using absolute or relative symlinks. An absolute symlink always points to the same file, even if the directory containing the link is moved. However, if the symlink is visible from more than one machine (such as on a networked file system), the file pointed to might not always be the same. A relative symbolic link is resolved in relation to the directory that contains the link, and is often useful in referring to files on the same device without regards to what name that device is mounted on when accessed via networked machines. When creating a relative symlink in a different location than the current directory, the resolution of the symlink will be different than the resolution of the same string from the current directory. Therefore, many users prefer to first change directories to the location where the relative symlink will be created, so that tab-completion or other file resolution will find the same target as what will be placed in the symlink.
Andreas Radke schrieb:
we have a bugreport to change a relative symlink to an absolute symlink
http://bugs.archlinux.org/task/14895. I don't really get the point where there difference will be and if the links would be broken when using different filesystems/partitions and links in itself.
I'd like to hear your opinions for a general packaging rule.
Without reading the bug report: relative links are almost always better than absolute ones.
On Sun, Jul 26, 2009 at 10:43 AM, Thomas Bächler<thomas@archlinux.org> wrote:
Andreas Radke schrieb:
we have a bugreport to change a relative symlink to an absolute symlink
http://bugs.archlinux.org/task/14895. I don't really get the point where there difference will be and if the links would be broken when using different filesystems/partitions and links in itself.
I'd like to hear your opinions for a general packaging rule.
Without reading the bug report: relative links are almost always better than absolute ones.
even when the relative link goes up to root? In this case the links are of the form ../../opt/openoffice/something - because the full path ends up in there _anyway_, I feel like the relative ../../ is unnecessary
On Sun, Jul 26, 2009 at 12:45 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Sun, Jul 26, 2009 at 10:43 AM, Thomas Bächler<thomas@archlinux.org> wrote:
Andreas Radke schrieb:
we have a bugreport to change a relative symlink to an absolute symlink
http://bugs.archlinux.org/task/14895. I don't really get the point where there difference will be and if the links would be broken when using different filesystems/partitions and links in itself.
I'd like to hear your opinions for a general packaging rule.
Without reading the bug report: relative links are almost always better than absolute ones.
even when the relative link goes up to root? In this case the links are of the form ../../opt/openoffice/something - because the full path ends up in there _anyway_, I feel like the relative ../../ is unnecessary
I agree on this point- the relative symlink in this case adds no convenience and only complexity. Maybe a more general rule can be something along the lines of "if the link crosses a feasible location for a mountpoint, use an absolute symlink"? For the most part, this will entail anything passing through '/' should not be relative. -Dan
Aaron Griffin schrieb:
even when the relative link goes up to root? In this case the links are of the form ../../opt/openoffice/something - because the full path ends up in there _anyway_, I feel like the relative ../../ is unnecessary
Let's say you want to mount your arch system on another machine and open files inside it (not chroot into it). The the symlinks still stay correct. They don't if they are absolute.
On Sun, Jul 26, 2009 at 1:20 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
even when the relative link goes up to root? In this case the links are of the form ../../opt/openoffice/something - because the full path ends up in there _anyway_, I feel like the relative ../../ is unnecessary
Let's say you want to mount your arch system on another machine and open files inside it (not chroot into it). The the symlinks still stay correct. They don't if they are absolute.
That's a fair point, but what use is an Arch system that's not chrooted into? I don't expect /mnt/archlinux/usr/bin/gtkpod to work on a CentOS system. It sounds like an edge case.
Aaron Griffin schrieb:
That's a fair point, but what use is an Arch system that's not chrooted into? I don't expect /mnt/archlinux/usr/bin/gtkpod to work on a CentOS system. It sounds like an edge case.
Not talking about binaries here, but generally messing around with random files on a mounted system. I often found myself in a great mess with absolute symlinks in the past, while relative never gave any downside.
On Mon, Jul 27, 2009 at 5:13 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
That's a fair point, but what use is an Arch system that's not chrooted into? I don't expect /mnt/archlinux/usr/bin/gtkpod to work on a CentOS system. It sounds like an edge case.
Not talking about binaries here, but generally messing around with random files on a mounted system. I often found myself in a great mess with absolute symlinks in the past, while relative never gave any downside.
A quick google returned me a similar discussion with similar arguments : https://www.zarb.org/pipermail/rpmlint-discuss/2006-June/000094.html And apparently they decided to prefer relative symlinks. However, the debian policy linked in the same post does not seem to have changed : "In general, symbolic links within a top-level directory should be relative, and symbolic links pointing from one top-level directory into another should be absolute. (A top-level directory is a sub-directory of the root directory /.) "
On Mon, Jul 27, 2009 at 10:23 AM, Xavier<shiningxc@gmail.com> wrote:
On Mon, Jul 27, 2009 at 5:13 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
That's a fair point, but what use is an Arch system that's not chrooted into? I don't expect /mnt/archlinux/usr/bin/gtkpod to work on a CentOS system. It sounds like an edge case.
Not talking about binaries here, but generally messing around with random files on a mounted system. I often found myself in a great mess with absolute symlinks in the past, while relative never gave any downside.
A quick google returned me a similar discussion with similar arguments : https://www.zarb.org/pipermail/rpmlint-discuss/2006-June/000094.html And apparently they decided to prefer relative symlinks.
However, the debian policy linked in the same post does not seem to have changed : "In general, symbolic links within a top-level directory should be relative, and symbolic links pointing from one top-level directory into another should be absolute. (A top-level directory is a sub-directory of the root directory /.) "
Think we should vote on this one? Do we care enough? I like the sound of the debian policy
Aaron Griffin schrieb:
However, the debian policy linked in the same post does not seem to have changed : "In general, symbolic links within a top-level directory should be relative, and symbolic links pointing from one top-level directory into another should be absolute. (A top-level directory is a sub-directory of the root directory /.) "
Think we should vote on this one? Do we care enough? I like the sound of the debian policy
I don't. It is inconsistent and there is no reason for absolute symlinks I could think of. That said, it's not really a topic that makes the world end if we do it wrong.
On Mon, Jul 27, 2009 at 12:35 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
However, the debian policy linked in the same post does not seem to have changed : "In general, symbolic links within a top-level directory should be relative, and symbolic links pointing from one top-level directory into another should be absolute. (A top-level directory is a sub-directory of the root directory /.) "
Think we should vote on this one? Do we care enough? I like the sound of the debian policy
I don't. It is inconsistent and there is no reason for absolute symlinks I could think of. That said, it's not really a topic that makes the world end if we do it wrong.
Relative symlinks seem downright dumb to me when you are passing through '/', but in the end, I don't care enough to write another email on this subject, so you've heard my vote. :) -Dan
Dan McGee wrote:
On Mon, Jul 27, 2009 at 12:35 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
However, the debian policy linked in the same post does not seem to have changed : "In general, symbolic links within a top-level directory should be relative, and symbolic links pointing from one top-level directory into another should be absolute. (A top-level directory is a sub-directory of the root directory /.) "
Think we should vote on this one? Do we care enough? I like the sound of the debian policy
I don't. It is inconsistent and there is no reason for absolute symlinks I could think of. That said, it's not really a topic that makes the world end if we do it wrong.
Relative symlinks seem downright dumb to me when you are passing through '/', but in the end, I don't care enough to write another email on this subject, so you've heard my vote. :)
Agreed. Meh++ Allan
participants (6)
-
Aaron Griffin
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Thomas Bächler
-
Xavier