without that simlink at least eselect opengl fails Switching to xorg-x11 OpenGL interface.../usr/share/eselect//libs/core.bash: line 115: /usr/bin/sed: No such file or directory !!! Error: Failed to create //usr/lib64/libGL.la exiting. >>> original instance of package unmerged safely. Switching to ati OpenGL interface.../usr/share/eselect//libs/core.bash: line 115: /usr/bin/sed: No such file or directory !!! Error: Failed to create //usr/lib32/libGL.la exiting.
See Bug 122082...
so there is need to add line to sed-4.1.4-r1 emerge output to re-emerge app-admin/eselect
(In reply to comment #2) > so there is need to add line to sed-4.1.4-r1 emerge output to re-emerge > app-admin/eselect No, that's completely wrong solution. :)
This is general eselect breakage, eselect-mysql is broken as well. *plop* # grep sed /usr/share/eselect/libs/core.bash # GNU sed wrapper (real path to GNU sed determined by configure) sed() { /usr/bin/sed "$@"
to complete eselect opengl i made manualy /etc/bin/sed -> /bin/sed then removed simlink and re-emerged eselect and it determined correct /bin/sed : # grep sed /usr/share/eselect/libs/core.bash # GNU sed wrapper (real path to GNU sed determined by configure) sed() { /bin/sed "$@"
workaround: emerge --oneshot eselect It will find the correct location, there is no need to make a symlink.
Yeah, what happens is that eselect's ./configure looks for sed in $PATH and hard codes the location in a source file. If your sed moves, you'll need to rebuild eselect. No clean solution for this one really.
*** Bug 122641 has been marked as a duplicate of this bug. ***
*** Bug 123887 has been marked as a duplicate of this bug. ***
*** Bug 128062 has been marked as a duplicate of this bug. ***
*** Bug 132805 has been marked as a duplicate of this bug. ***
*** Bug 134092 has been marked as a duplicate of this bug. ***
*** Bug 165495 has been marked as a duplicate of this bug. ***
*** Bug 168631 has been marked as a duplicate of this bug. ***
And adding a dosym /bin/${PN} /usr/bin/${PN} to sed ebuilds would be a right solution?
(In reply to comment #15) > And adding a > dosym /bin/${PN} /usr/bin/${PN} > to sed ebuilds would be a right solution? As said in Comment #7, re-emerge eselect.
*** Bug 246523 has been marked as a duplicate of this bug. ***
...why does eselect need to call sed via an absolute path? Shouldn't PATH suffice for this even in tricky cases like prefixs installs??
(In reply to Ian Stakenvicius from comment #18) > ...why does eselect need to call sed via an absolute path? Shouldn't PATH > suffice for this even in tricky cases like prefixs installs?? The location is determined at configure time, because the GNU sed binary can be installed under a different name (e.g. /usr/bin/gsed on BSD). See the snippet from configure.ac below. # AC_PROG_SED doesn't work here, because on Gentoo FreeBSD systems it # is confused by a wrapper script that is in the PATH at build time. AC_PATH_PROGS(SED, [gsed sed]) if test x$SED = x; then AC_MSG_ERROR([sed is required]) fi AC_MSG_CHECKING([whether $SED is GNU sed]) if $SED 'v4.0' </dev/null >/dev/null 2>&1; then AC_MSG_RESULT(yes) else AC_MSG_RESULT(no) AC_MSG_ERROR([GNU sed is required]) fi
(In reply to Ulrich Müller from comment #19) that doesn't answer Ian's stated question :). let me be more specific: why does eselect use AC_PATH_PROGS instead of AC_CHECK_PROGS ?
(In reply to SpanKY from comment #20) The whole purpose of the wrapper functions is to get well defined versions of programs at run time, therefore fixed paths are used. PATH could be different at configure time and run time.
(In reply to Ulrich Müller from comment #21) that's an argument for relying on `gsed` instead of `sed`, but the aspect about $PATH changing doesn't muster much imo. that same argument could be applied to just about every package in the tree and thus far, we've explicitly taken the approach that compiling in absolute paths is wrong and people should be using $PATH. we've been going as far as fixing packages that attempt to compile in absolute paths because they then break if those packages move binaries around (like /sbin -> /bin or /bin -> /usr/bin).
(In reply to SpanKY from comment #22) > [...] thus far, we've explicitly taken the approach that compiling in > absolute paths is wrong and people should be using $PATH. Where is that policy defined?
(In reply to SpanKY from comment #20) In git now: https://gitweb.gentoo.org/proj/eselect.git/commit/?id=da9a451824ccd5e4e2b9be405fecad82599ba702
Fixed in eselect-1.4.6.
