Re: Relative and absolute symlinks
On Wed, Aug 27, 2008 at 09:57:58AM -0500, Manoj Srivastava wrote: Rhonda made the suggestion that we allow absolute links /usr/* and /var/* symlinks to be absolute between different hierarchies, since these hierarchies are often the target of relocation-via-symlinking. A suggestion was made that links in the /usr/share/doc/ hierarchy could remain relative (/usr/share/doc/bash-doc/examples - ../bash/examples, perhaps for the reason that people are unlikely to move just one directory out of /usr/share/doc/ via symlinks, and we might as well not break case 2 for folks. I think case 1 is more important than case 2, since the latter is a convenience and useful for remote admin, but case 1 helps out the local machine, and is often a godsend in critical nearly out of disk space on important server situation. Do we have consensus that a: a) links that do not climb directory trees should be encouraged to be relative (do not break case 2) b) subdirectories of /var/*/ and /usr/* should be treated as top level directories for the purposes of the relative/absolute symlink rule: any links that climbs out of /usr/foo/bar or /var/foo/bar should be absolute, and the rest of the current rule stays in place? I agree that this is reasonable. I think that b) is fairly unnecessary anymore because of bind mounts, but I think it's logically consistent with the existing policy if we draw the line there. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
Hi, To summarize, here are a few use cases: 1) A directory that lives in the package is replaced by a symbolic link to another partition (I've done it in a space crunch, people sharing directories using AFS run into similar issues.) 2) Remote mounting a directory from one machine on to another with a different path (I often use sshfs to work on remote machines, people using NFS also fall into this category In case 1, relative symlinks pointing outside the heirarchy break; since the relative path to an external file is different from the old and the new location. Example: /var/lib/foo -- /u/foo /var/lib/foo/log should point to /var/logs/foo.log /u/foo/log -- /var/logs/foo.log --- works /u/foo/log -- ../../logs/foo.log --- fails In case A, symlinks pointing inside the path hierarchy continue to work (that is, a symlink with no ../ path component are sure to work, symlinks pointing up will break is the local relocation is in that upward path). So, I agree with Russ that symbolic links in the same tree should be encouraged, since that helps out in case 2, and does not break case 1. In case 2, absolute paths in the same directory tree would point to the work machine, not to the files they point to. Example: machineA:/var mounted on /mnt/machineA /var/lib/foo/log should point to /var/logs/foo.log /u/foo/log -- ../../logs/foo.log --- Works /u/foo/log -- /var/logs/foo.log --- fails (points to my foo.log, not MachneA's) The original policy was supposed to allow the latter to work as well, but it all boils down to common case. I often use sshfs, but that might not be the common case. Rhonda made the suggestion that we allow absolute links /usr/* and /var/* symlinks to be absolute between different hierarchies, since these hierarchies are often the target of relocation-via-symlinking. A suggestion was made that links in the /usr/share/doc/ hierarchy could remain relative (/usr/share/doc/bash-doc/examples - ../bash/examples, perhaps for the reason that people are unlikely to move just one directory out of /usr/share/doc/ via symlinks, and we might as well not break case 2 for folks. I think case 1 is more important than case 2, since the latter is a convenience and useful for remote admin, but case 1 helps out the local machine, and is often a godsend in critical nearly out of disk space on important server situation. Do we have consensus that a: a) links that do not climb directory trees should be encouraged to be relative (do not break case 2) b) subdirectories of /var/*/ and /usr/* should be treated as top level directories for the purposes of the relative/absolute symlink rule: any links that climbs out of /usr/foo/bar or /var/foo/bar should be absolute, and the rest of the current rule stays in place? manoj -- Linux poses a real challenge for those with a taste for late-night hacking (and/or conversations with God). (By Matt Welsh) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
Manoj Srivastava [EMAIL PROTECTED] writes: Do we have consensus that a: a) links that do not climb directory trees should be encouraged to be relative (do not break case 2) b) subdirectories of /var/*/ and /usr/* should be treated as top level directories for the purposes of the relative/absolute symlink rule: any links that climbs out of /usr/foo/bar or /var/foo/bar should be absolute, and the rest of the current rule stays in place? Personally, I would be happy with that change. It makes sense to me. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
On Wed, Aug 27, 2008 at 09:57:58AM -0500, Manoj Srivastava wrote: Do we have consensus that a: a) links that do not climb directory trees should be encouraged to be relative (do not break case 2) b) subdirectories of /var/*/ and /usr/* should be treated as top level directories for the purposes of the relative/absolute symlink rule: any links that climbs out of /usr/foo/bar or /var/foo/bar should be absolute, and the rest of the current rule stays in place? Fine with me. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
On Wed, Aug 27, 2008 at 09:57:58AM -0500, Manoj Srivastava wrote: Hi, To summarize, here are a few use cases: 1) A directory that lives in the package is replaced by a symbolic link to another partition (I've done it in a space crunch, people sharing directories using AFS run into similar issues.) I think case 1 is more important than case 2, since the latter is a convenience and useful for remote admin, but case 1 helps out the local machine, and is often a godsend in critical nearly out of disk space on important server situation. Not really anymore, since linux 2.6 allows to bind-mount directories and files which is generally more robust than symlinks. Maybe it is time to sanction this approach over the use of symlinks. One issue with symlink in the current arrangement is that it is difficult to link files to packages, see bug #246006. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
* Manoj Srivastava [EMAIL PROTECTED] [2008-08-27 16:57:58 CEST]: Do we have consensus that a: a) links that do not climb directory trees should be encouraged to be relative (do not break case 2) b) subdirectories of /var/*/ and /usr/* should be treated as top level directories for the purposes of the relative/absolute symlink rule: any links that climbs out of /usr/foo/bar or /var/foo/bar should be absolute, and the rest of the current rule stays in place? That would totally be along the lines that I thought and I'm glad that others think the idea makes sense, too. Thanks. :) Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
Lionel Elie Mamane wrote: (Further discussion should happen on [EMAIL PROTECTED], but please CC me.) During Manoj's policy talk at DebConf8, Gerfried opened the subject of the policy's stand on relative and absolute symlinks, which currently is absolute if going through top-level, relative otherwise. I wanted to give another data-point: Mailman switched its intra-/var/ symlinks to be absolute, because relative symlinks there broke setups of people that moved their /var/lib/mailman/ directory to another partition, not through mounting, but through replacing their /var/lib/mailman/ directory by a symlink to elsewhere - e.g. /u/mailman . This broke e.g. relative symlinks /var/lib/mailman/log to ../../logs/mailman. Bugs #413604 and #408855 contain the whole story. As policy doesn't technically *mandate* relative symlinks, but says in general, we felt we could deviate from our own initiative. I must say I don't quite see in what scenario relative symlinks make something work that absolute symlinks do not make work. So, is there any reason at all to use relative symlinks? I think it was done for efficiency, but I think correctness is more important. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
* Lionel Elie Mamane [EMAIL PROTECTED] [2008-08-15 16:47:41 CEST]: (Further discussion should happen on [EMAIL PROTECTED], but please CC me.) Same with me, I plan to scan the archives of the list, but am not subscribed. During Manoj's policy talk at DebConf8, Gerfried opened the subject of the policy's stand on relative and absolute symlinks, which currently is absolute if going through top-level, relative otherwise. I wanted to give another data-point: Mailman switched its intra-/var/ symlinks to be absolute, because relative symlinks there broke setups of people that moved their /var/lib/mailman/ directory to another partition, not through mounting, but through replacing their /var/lib/mailman/ directory by a symlink to elsewhere - e.g. /u/mailman . This broke e.g. relative symlinks /var/lib/mailman/log to ../../logs/mailman. Bugs #413604 and #408855 contain the whole story. The story was raised for me by different users of the wesnoth package. People seem to move at least their /usr/games section to some other place and symlink it because of its size. I also am aware that there are people doing the same for /var/spool. In general my suggestion was to at least allow /usr/* and /var/* symlinks to be absolute between different hierarchies in there instead of putting the weight of a should in there. Rationale being that the structure within /usr and /var is quite split up and it does make sense to allow people to do the same stuff with direct root directories without any pains. I must say I don't quite see in what scenario relative symlinks make something work that absolute symlinks do not make work. So, is there any reason at all to use relative symlinks? Quite some times I experienced them to be more pain than gain, too. It might be useful if people shift around complete hierarchies, but we are not really speaking of package-internal symlinks here usually. Thanks, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
Gerfried Fuchs [EMAIL PROTECTED] writes: * Lionel Elie Mamane [EMAIL PROTECTED] [2008-08-15 16:47:41 CEST]: So, is there any reason at all to use relative symlinks? Quite some times I experienced them to be more pain than gain, too. It might be useful if people shift around complete hierarchies, but we are not really speaking of package-internal symlinks here usually. And Debian doesn't support relocatable packages in general anyway. We should clearly use relative symlinks within the same directory, and probably from a directory to a subdirectory, but I do wonder about the merits of any symlink containing ../. I'm not sure what we'd lose by making any symlink that climbs directories absolute instead of relative, and I think we'd definitely gain from having somewhat less weirdness and breakage in corner cases. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
On Fri, Aug 15, 2008 at 07:49:14PM +0200, Gerfried Fuchs wrote: * Lionel Elie Mamane [EMAIL PROTECTED] [2008-08-15 16:47:41 CEST]: During Manoj's policy talk at DebConf8, Gerfried opened the subject of the policy's stand on relative and absolute symlinks, which currently is absolute if going through top-level, relative otherwise. So, is there any reason at all to use relative symlinks? I had a quick chat with Manoj, and he makes the following point: Say someone has the /usr/share/doc of a Debian machine on a separate partition, say /dev/sdb7. Now, he boots into a FreeBSD installation on the same machine and mounts /dev/sdb7 on /mnt/debian-doc; then relative symlinks within the Debian /usr/share/doc work, but absolute symlinks don't. Similarly, if one NFS-mounts Debian's /usr/share/doc on /mnt/debian-doc of another machine. Or accessing a file from a chroot from the parent filesystem (without actually chrooting into the chroot). One could argue that to handle this scenario, Unices need an additional mounting option map-symlinks=/usr/share/doc that would strip /usr/share/doc from absolute symlinks in that partition and (if it stripped) stick the mount point path in front of them. However, having the whole world change in order to accommodate our eventual only absolute symlinks policy is not a practical solution :) My gut feeling is that make everything work within Debian takes priority over make rarer / manually setup scenarios work when there is a hard conflict, meaning we should use absolute symlinks when the conflict arises. In other words, for a specific directory, our good reason to disallow relative symlinks through it (that is it may be a symlink itself) outweighs our good reason to require relative symlinks through it (that is, it may be mounted elsewhere), in cases both apply. A maybe out-of-the-hand way to make the problem disappear is to specify our users should not use symlinks to move things to another physical place, but that they should use only mounts (I'm thinking of rbind mounts to a shared mount to replace symlinks). Then, all relative symlinks is good. If we don't do that, the core question is what directory is somewhat likely to be a separate partition / symlink to elsewhere? (And a symlink that escapes the scope of such a directory must then be absolute.) My list would be: - most top-level directories: /var, /usr, /opt, /boot, /home, /srv/ - /usr/local - most (direct) subdirectories of /var/ or /usr/ - actually, any big (in space)) hierarchy; /usr/share/games, /usr/share/docs, /var/lib/mysql, ... and some package-specific directories. To take the example of mailman, I can imagine people doing that with the whole /var/lib/mailman, but also with only /var/lib/mailman/archives or /etc/mailman/templates. So it seems hard to have a predefined list in policy; maybe we should document the problem in the reference manual and let maintainers make case-by-case decisions. Or policy could say something along the lines of: A symlink must be relative if it escapes the scope of a directory that users may, for reasons of size, different mount options or other, want to replace by a symlink to another physical location. Examples include the top-level directories, /usr/share/doc, /usr/share, /var/log, ... -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
On Fri, Aug 15, 2008 at 11:42:23AM -0700, Russ Allbery wrote: Gerfried Fuchs [EMAIL PROTECTED] writes: * Lionel Elie Mamane [EMAIL PROTECTED] [2008-08-15 16:47:41 CEST]: So, is there any reason at all to use relative symlinks? Quite some times I experienced them to be more pain than gain, too. It might be useful if people shift around complete hierarchies, but we are not really speaking of package-internal symlinks here usually. And Debian doesn't support relocatable packages in general anyway. Well, users are not feeling they are relocating a package when replacing one of its directories by a symlink to elsewhere; after all, paths of the form /original/package/file/patch still work. We should clearly use relative symlinks within the same directory, and probably from a directory to a subdirectory, but I do wonder about the merits of any symlink containing ../. I'm not sure what we'd lose by making any symlink that climbs directories absolute instead of relative, and I think we'd definitely gain from having somewhat less weirdness and breakage in corner cases. Well, these symlink for example: /usr/share/doc/bash/completion-contrib - ../bash-completion/contrib /usr/share/doc/bash-doc/examples - ../bash/examples /usr/share/doc/cpp/README.Bugs - ../gcc-4.2/README.Bugs should IMHO stay relative, because of the scenario described by Manoj, and users are extremely unlikely to replace a subdirectory of /usr/share/doc by a symlink (except /usr/share/doc/texmf?). But maybe managing such exceptions would be too hairy altogether and we'd want a much simpler policy in exchange for only 99.9% correctness. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
Lionel Elie Mamane [EMAIL PROTECTED] writes: On Fri, Aug 15, 2008 at 11:42:23AM -0700, Russ Allbery wrote: Gerfried Fuchs [EMAIL PROTECTED] writes: Quite some times I experienced them to be more pain than gain, too. It might be useful if people shift around complete hierarchies, but we are not really speaking of package-internal symlinks here usually. And Debian doesn't support relocatable packages in general anyway. Well, users are not feeling they are relocating a package when replacing one of its directories by a symlink to elsewhere; after all, paths of the form /original/package/file/patch still work. That wasn't the sort of relocation that I meant. My point was that using relative symlinks to support moving a tree of installed files to some other different path (from /usr/lib to /opt/foo, say) isn't something that our package manager supports. But your other message lays out a scenario where that does make sense. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
