When try to compile xmms using portage-2.0.47-r8 I got xmms plugins placed in /usr/lib instead of /usr/lib/xmms/<type of plugin>/ . After some research it was found that ebuild passes param libdir to make (on install stage) thus overriding correct value from Makefiles. How to reproduce this bug: ebuild /usr/portage/media-sound/xmms/xmms-1.2.7-r15.ebuild compile mv /usr/bin/make /usr/bin/make-old echo '#!/bin/sh echo arguments: env echo args: echo $* exec /usr/bin/make-old "$@"' > /usr/bin/make chmod +x /usr/bin/make ebuild /usr/portage/media-sound/xmms/xmms-1.2.7-r15.ebuild install This error may affect other packages as well
with portage-2.0.46-r12 everything works Ok, so probably this portage bug was introduced later.
yes, it was introduced later ...
the question is, do we want to say the install script is broken or the ebuild.sh ? :/
I think ebuild.sh is broken. We cannot force all developers to use vars like libdir in some "right" way. Developers may use these vars as they want. autoconf is not the univesal standard :)
many packages will append their path specific information to libdir ... usually when you pass a variable to make you expect to be setting the base of the path, not the whole thing ... when i give make 'prefix=${D}/usr', i dont expect all the files to be in ${D}/usr ... i expect it to use ${D}/usr as the base of the tree but thats me ;)
Some developers don't use autoconf so meaning of such variables is undefined for these packages. Setting libdir, incdir and so on is package dependent and must be placed in .ebuild files. libdir should be set by `configure' script, there should be no need in specifying it once again on install. make has a feature: if variable has been set in environment (or as argument to make), Makefile settings by default does not override this value. E.g. in xmms, there is line like libdir = $(plugindir)/$(OUTPUT_PLUGIN_DIR) in plugin directory's Makefile. But since libdir has already been set on make invocation, this directive is ignored. Of course, it is possible to explicitly override old value using 'override libdir=...', but I guess we should not force developers to do that.
This bug is the same issue as 16803 - -r19 of the XMMS ebuild corrects this issue. Can this revision be marked stable?
*** This bug has been marked as a duplicate of 16599 ***
