Relative links offer an advantage over absolute links, which is that they don't break if both the target and the link are moved, which is why relative symlinks aid binary distribution, which could speed up and ease bootstrapping, thereby attract more users, etc. (and come in handy whenever one is short on time and/or on a slow system). So, conclusively, absolute paths offer no benefit and relative paths are just *great*. So much for my - I'd appreciate noise in case I'm missing something here of course - otherwise I'll go ahead and start the transition from absolute to relative paths sometime soon, a couple of ebuilds will be affected but not a lot. I'll attach the patches to this bug before I commit anything.
Created attachment 128060 [details, diff] first patch % grep Index relative-symlinks_1.patch Index: app-admin/eselect/files/eselect-1.0.10-relative-symlinks.patch Index: app-admin/eselect-vi/files/eselect-vi-1.1.5-prefix.patch Index: app-admin/eselect/eselect-1.0.10.ebuild Index: app-arch/tar/tar-1.18-r1.ebuild Index: app-editors/nano/nano-2.0.6.ebuild Index: mail-client/mutt/mutt-1.5.16.ebuild Index: mail-mta/ssmtp/ssmtp-2.61-r2.ebuild Index: net-mail/mailbase/mailbase-1.ebuild Index: sys-apps/coreutils/coreutils-6.9-r1.ebuild Index: sys-apps/gawk/gawk-3.1.5-r4.ebuild Index: sys-devel/m4/m4-1.4.9-r1.ebuild
Created attachment 128072 [details, diff] second patch % grep Index relative-symlinks_2.patch Index: files/binutils-config-1.9 this is *by far* the worst of them all.
Created attachment 128087 [details, diff] second patch, second try % grep Index relative-symlinks_2.patch Index: sys-devel/binutils-config/files/binutils-config-1.9 new patch for the same file (additional changes, though)
(In reply to comment #0) > Relative links offer an advantage over absolute links, which is that they don't > break if both the target and the link are moved, which is why relative symlinks > aid binary distribution, which could speed up and ease bootstrapping, thereby > attract more users, etc. (and come in handy whenever one is short on time > and/or on a slow system). So, conclusively, absolute paths offer no benefit and > relative paths are just *great*. Alternatively, just readlink the symlink, and if absolute, change it like you change any other reference for a normal file. It just ends up being a switch case based on object type what you need to do. Even though jailer now can work fine on text files, one might just want to run sed on it, as that's cheaper. Only run jailer on binaries, and change the target if absolute on symlinks.
% strings ~/Gentoo/bin/bash | grep Gentoo /Users/pipping/Gentoo/etc/bash/bashrc /Users/pipping/Gentoo/etc/profile /Users/pipping/Gentoo/usr/sbin:/Users/pipping/Gentoo/usr/bin:/Users/pipping/Gentoo/sbin:/Users/pipping/Gentoo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /Users/pipping/Gentoo/etc/hosts /Users/pipping/Gentoo/bin:/Users/pipping/Gentoo/usr/bin:/Users/pipping/Gentoo/sbin:/Users/pipping/Gentoo/usr/sbin:/bin:/usr/bin:/sbin:/usr/sbin /Users/pipping/Gentoo/etc/bash/bash_logout I'd say that's not fun to do with sed, given the nullbytes need to conglomerate at the end of the line.
re-read please.
> Alternatively, just readlink the symlink, and if absolute, change it like you > change any other reference for a normal file. It just ends up being a switch > case based on object type what you need to do. Even though jailer now can work > fine on text files, one might just want to run sed on it, as that's cheaper. > Only run jailer on binaries, and change the target if absolute on symlinks. > Where would you want that functionality? in a wrapper for jailer+install_name_tool?
When portage installs from a binary package, then I think right after unpacking you would run on every file some tool to the the prefix right. I can therefore imagine (I'm happy to try that out with my old iBook) that I would maintain a special prefix install using an ugly long prefix which compiles with very portable CFLAGS to create binary packages which portage then unpacks on the target machine, and sets the target prefix.
so, what about this? if this has been decided against, the ticket should be closed.
the majority of the developers (1 out of 1) has raised objections to this approach, so cloding.
