[arch-dev-public] general packaging question about symlinks

26 Jul 2009

      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

Thomas Bächler

Aaron Griffin

Dan McGee

Thomas Bächler

Aaron Griffin

Thomas Bächler

Xavier

Aaron Griffin

Thomas Bächler

Dan McGee

Allan McRae

tags

participants (6)