I'm using emerge to install a set of tools in an other $ROOT directory as the default '/', for instance /usr/local/src/bootstrap. actually, emerge won't create good links but ebuild ... install does. The issue appends with app-editors/vim-7.2.402 for example. ebuild vim install is okay, # ls -l /var/tmp/portage/app-editors/vim-7.2.402/image/usr/bin/ total 0 lrwxrwxrwx 1 root root 3 13 avril 16:12 rview -> vim lrwxrwxrwx 1 root root 3 13 avril 16:12 rvim -> vim lrwxrwxrwx 1 root root 3 13 avril 16:12 vimdiff -> vim but # ROOT=/usr/local/src/bootstrap LINGUAS="fr" USE="-* nls nptl openmp extras unicode pcre gpm ssl readline threads ncurses gd mudflap -gcj gdbm sqlite tcpd libedit -pam slang caps acl icu threadsafe fts3 gmp bindist zlib bzip2 crypt xattr" emerge -1 vim lrwxrwxrwx 1 root root 37 13 avril 16:12 vi -> /usr/local/src/bootstrap//usr/bin/vim lrwxrwxrwx 1 root root 37 13 avril 16:12 view -> /usr/local/src/bootstrap//usr/bin/vim is not # find . -type l -lname "/usr/local/*" ./usr/bin/vi ./usr/bin/ex ./usr/bin/view ./usr/share/vim/vim72/doc/gentoo-syntax.txt are affected as well. Reproducible: Always # emerge --info Portage 2.2_rc67 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.11-r1, 2.6.34-rc3-radeon x86_64) ================================================================= System uname: Linux-2.6.34-rc3-radeon-x86_64-AMD_Phenom-tm-_9500_Quad-Core_Processor-with-gentoo-2.0.1 Timestamp of tree: Tue, 13 Apr 2010 04:15:02 +0000 distcc 3.1 x86_64-pc-linux-gnu [enabled] app-shells/bash: 4.1_p5 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.5-r1, 3.1.2-r2 dev-python/pycrypto: 2.1.0 dev-util/cmake: 2.8.1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1 sys-devel/gcc: 4.4.3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA MIT GPL-3 PSF-2.2 X11 GPL-2 ETQW RTCW-ETEULA ut2003" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=barcelona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/splash/livecd-2007.0/1280x1024.cfg /lib/rcscripts/addons /sbin/rc /sbin/splash-functions-bl1.sh /sbin/splash-functions.sh /usr/local/share/cursors/xorg-x11/default/index.theme /usr/share/X11/xkb /usr/share/hddtemp/hddtemp.db /usr/src/linux/.config /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=barcelona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests collision-protect distcc distlocks fixpackages metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unmerge-logs unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" LANG="fr_FR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="fr" MAKEOPTS="-j8 -l5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/science /var/lib/layman/x11 /var/lib/layman/sunrise /var/lib/layman/gnome /usr/local/portage/java /usr/local/portage/overlay" SYNC="rsync://.../gentoo-portage" USE="3dnow 3dnowext acl amd64 avahi bindist bzip2 cli cracklib crypt cups cxx dbus dri expat gdbm gpm iconv latex logrotate maildir mmx mmxext modules mudflap multilib ncurses nls nptl nptlonly ogg openmp pam pcre perl pppd pulseaudio python readline reflection session spl sse sse2 ssl ssse3 sysfs tcpd threads udev unicode userlocales vorbis xinetd xorg xulrunner zlib" ALSA_CARDS="hda-intel usb-audio virmidi" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" CAMERAS="ptp2" DVB_CARDS="usb-wt220u" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr" LIRC_DEVICES="devinput userspace" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeonhd" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Again, nothing to do with portage - it's vim.eclass making symlinks in /usr/bin without prefix support. Please research this better instead of blaming everything on the package manager!
(In reply to comment #1) > Again, nothing to do with portage - it's vim.eclass making symlinks in /usr/bin > without prefix support. Please research this better instead of blaming > everything on the package manager! > Doesn't vim.eclass belongs to portage ? It is in /usr/portage/eclass as I can read. So please don't take it too personal or I will become tired to play with gentoo
(In reply to comment #2) > Doesn't vim.eclass belongs to portage ? It is in /usr/portage/eclass as I can > read. No, it doesn't. top of the file says it is maintained by the vim herd. > So please don't take it too personal or I will become tired to play with gentoo I am a volunteer on this project as are all developers. I have no intent to play nice with you just to keep you from switching distros, and our time is valuable so please do not waste it.
I have no intent to > play nice with you just to keep you from switching distros, and our time is > valuable so please do not waste it. Like most of the people here I'm a volunteer reporter. I'm not paid to find out bugs neither to correct them and moreover I'm no more student for a while and certainly have less time as you have. If I'm well informed you are or have been the lead developer of 'The Bug Wranglers Project'. Please, stay fair on what you told others to do, excerpts (http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml), In general, be gentle in your verbal assessment of a bug report. Even if you are quite certain that it's going to be resolved as INVALID, you should treat the reporter courteously. Assume that the reporter can help but may not know how, without either suggesting he may not know how or assuming he does know how. Please, reassign bug to vim@gentoo.org if that what should be done. Thx PS: FYI, I don't need distros to build a professional and well featured desktop/server. Case closed
I don't yet fully understand what's going on, but I think we are involved here
(In reply to comment #5) > I don't yet fully understand what's going on, but I think we are involved here Yes, that was my impression. I thought it's because of these but I might be wrong: jeroen@astrid /keeps/gentoo/cvs/gentoo-x86/eclass $ grep -n dosym.*\/usr\/bin\/ vim.eclass 572: dosym gvim /usr/bin/gvimdiff 573: dosym gvim /usr/bin/evim 574: dosym gvim /usr/bin/eview 575: dosym gvim /usr/bin/gview 576: dosym gvim /usr/bin/rgvim 577: dosym gvim /usr/bin/rgview 595: dosym vim /usr/bin/vimdiff 596: dosym vim /usr/bin/rvim 597: dosym vim /usr/bin/rview 599: dosym ${vimfiles}/macros/less.sh /usr/bin/vimpager 600: dosym ${vimfiles}/macros/manpager.sh /usr/bin/vimmanpager
So, Jimmy.Jazz, to clear things up for everyone, would you mind posting a full list of: As a result of 'ebuild ... install': -> Which symlinks are correct and where do they legitimately point? -> Which (if any) symlinks are incorrect and where you think they should be pointing? As a result of 'emerge': -> Which symlinks are correct and where do they legitimately point? -> Which symlinks are incorrect and where you think they should be pointing?
Or perhaps this bit: jeroen@astrid /keeps/gentoo/cvs/gentoo-x86/eclass $ grep -n ln.*\/usr\/bin\/ vim.eclass 631: ln -s gvim "${EROOT}"/usr/bin/vim 2>/dev/null 639: ln -s vim "${EROOT}"/usr/bin/${f} 2>/dev/null
Or perhaps if it is the 'vi' and 'view' symlinks that are wrong, it's eselect-vi at fault instead. Hopefully we can figure out what's really going on here.
(In reply to comment #7) > So, Jimmy.Jazz, to clear things up for everyone, would you mind posting a full > list of: Sorry if I wasn't precise enough. You will need to install python in the new ${ROOT} directory or set USE='-*'. Otherwise you get an, * ERROR: app-editors/vim-7.2.411 failed: * python_set_active_version(): '=dev-lang/python-2*' is not installed The ebuild command for the test is, ROOT=/var/tmp/test USE="-*" ebuild /usr/portage/app-editors/vim/vim-7.2.411.ebuild install > As a result of 'ebuild ... install': > -> Which symlinks are correct and where do they legitimately point? > -> Which (if any) symlinks are incorrect and where you think they should be > pointing? The symlinks are pointing directly to the filename without their pathname. (see first hash sign in my first comment). ./usr/bin: total 1648 lrwxrwxrwx 1 root root 3 23 avril 16:38 rview -> vim lrwxrwxrwx 1 root root 3 23 avril 16:38 rvim -> vim -rwxr-xr-x 1 root root 1685680 23 avril 16:38 vim lrwxrwxrwx 1 root root 3 23 avril 16:38 vimdiff -> vim > As a result of 'emerge': > -> Which symlinks are correct and where do they legitimately point? > -> Which symlinks are incorrect and where you think they should be pointing? > None the above symlinks are wrong and the others symlinks are pointing to their full pathname with ${ROOT} included (see second hash sign in my first comment) The emerge command is, ROOT=/var/tmp/test USE="-*" emerge -O vim # ls -l ./usr/bin total 1648 lrwxrwxrwx 1 root root 26 23 avril 17:24 ex -> /var/tmp/test//usr/bin/vim lrwxrwxrwx 1 root root 3 23 avril 17:24 rview -> vim lrwxrwxrwx 1 root root 3 23 avril 17:24 rvim -> vim lrwxrwxrwx 1 root root 26 23 avril 17:24 vi -> /var/tmp/test//usr/bin/vim lrwxrwxrwx 1 root root 26 23 avril 17:24 view -> /var/tmp/test//usr/bin/vim -rwxr-xr-x 1 root root 1685680 23 avril 17:23 vim lrwxrwxrwx 1 root root 3 23 avril 17:24 vimdiff -> vim And confirmed by find command: # cd /var/tmp/test # find . -type l -lname "/var/tmp/*" ./usr/bin/view ./usr/bin/ex ./usr/bin/vi
(In reply to comment #10) > # ls -l ./usr/bin > total 1648 > lrwxrwxrwx 1 root root 26 23 avril 17:24 ex -> /var/tmp/test//usr/bin/vim > lrwxrwxrwx 1 root root 3 23 avril 17:24 rview -> vim > lrwxrwxrwx 1 root root 3 23 avril 17:24 rvim -> vim > lrwxrwxrwx 1 root root 26 23 avril 17:24 vi -> /var/tmp/test//usr/bin/vim > lrwxrwxrwx 1 root root 26 23 avril 17:24 view -> > /var/tmp/test//usr/bin/vim > -rwxr-xr-x 1 root root 1685680 23 avril 17:23 vim > lrwxrwxrwx 1 root root 3 23 avril 17:24 vimdiff -> vim > > And confirmed by find command: > # cd /var/tmp/test > # find . -type l -lname "/var/tmp/*" > ./usr/bin/view > ./usr/bin/ex > ./usr/bin/vi So, if I am reading this correctly, I believe you are saying that the symlinks for 'vi' 'view' and 'ex' are wrong because they are pointing at the full path to the executable and not the relative path? First of all, the three symlinks you are wondering about 'vi' 'view' and 'ex' are created in the pkg_postinst phase, which of course will not be executed if you just do 'emerge ... install'. They are created when you do 'emerge...' because it merges the package to the live filesystem and then runs pkg_postinst which creates these symlinks. You would also see these symlinks if you did 'emerge ... merge' since that also merges the package to the live filesystem. Secondly, vim.eclass does not actually create these symlinks, but uses 'app-admin/eselect-vi' to do the work. Finally, in what way are these symlinks incorrect or bad? They are absolute symlinks that are accurately pointing into ${ROOT} like you requested when you specified ROOT=/var/tmp/test
(In reply to comment #11) > (In reply to comment #10) > > # ls -l ./usr/bin > > total 1648 > > lrwxrwxrwx 1 root root 26 23 avril 17:24 ex -> /var/tmp/test//usr/bin/vim > So, if I am reading this correctly, I believe you are saying that the symlinks > for 'vi' 'view' and 'ex' are wrong because they are pointing at the full path > to the executable and not the relative path? no, they include $ROOT, which isn't going to work as soon as you chroot or whatever else into $ROOT. /usr/bin/vim would've been ok IMO. > First of all, the three symlinks you are wondering about 'vi' 'view' and 'ex' > are created in the pkg_postinst phase, which of course will not be executed if > you just do 'emerge ... install'. They are created when you do 'emerge...' > because it merges the package to the live filesystem and then runs pkg_postinst > which creates these symlinks. You would also see these symlinks if you did > 'emerge ... merge' since that also merges the package to the live filesystem. > > Secondly, vim.eclass does not actually create these symlinks, but uses > 'app-admin/eselect-vi' to do the work. > > Finally, in what way are these symlinks incorrect or bad? They are absolute > symlinks that are accurately pointing into ${ROOT} like you requested when you > specified ROOT=/var/tmp/test You'd want that if you'd used EPREFIX=/var/tmp/test.
(In reply to comment #12) I agree. Moreover libraries in $ROOT/ are relative to ${ROOT}, so should symlinks too. Actually, that's a great feature of portage tools that should be preserved.
(In reply to comment #13) > Moreover libraries in $ROOT/ are relative to ${ROOT}, so should symlinks too. > > Actually, that's a great feature of portage tools that should be preserved. Okay, so the problem is definitely app-admin/eselect-vi, which should *NOT* use ${ROOT} when creating symlinks. time to find out who's in charge of that package these days...
Aha, this is a known issue. Solved by bug #260593
Removing prefix@g.o
This should be fixed in app-admin/eselect-vi-1.1.7 After upgrading to eselect-vi-1.1.7 run 'eselect vi set vim' as root.
