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]
Relative and absolute symlinks
(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? -- 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 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: Bug#436105: suggestion to add GPL-1 as a common licence
On Thu, Aug 23, 2007 at 01:28:22PM +0200, Santiago Vila wrote: There are still many packages that mention the GPL version 1 in their copyright file (around 350). Many Perl packages, but also Perl itself and widespread things like sed, joe, cvs, dict... Nitpick: sed says GPLv2 or later -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361418: [Proposal] new Debian menu structure
On Mon, May 15, 2006 at 12:10:36AM +0900, Charles Plessy wrote: My reasonning was that if people install the packages ncbi-tools-*, they necessarly know what the NCBI is. It means at least one person on the machine knows. The other users will see a cryptic NCBI and think WTF is that?. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
