According to: http://forums.gentoo.org/viewtopic.php?t=169689&highlight=unsermake to tell a KDE package to use unsermake, one sets the UNSERMAKE variable. This works for every KDE package I've installed for the past month or so, but kipi-plugins ignores the variable. I have to symlink the unsermake executable to /usr/bin (or somewhere else in the path) to get kipi-plugins to see it.
This behavior changed in newer KDE build scripts, now the path to unsermake should just be added to PATH for it to work. It can be disabled by exporting UNSERMAKE=no. See also http://wiki.kde.org/tiki-index.php?page=unsermake
> This behavior changed in newer KDE build scripts, now the path to unsermake > should just be added to PATH for it to work So... is the unsermake ebuild going to install itself into the path? Should I submit a bug report for this? I say this because, if it isn't obvious, emerging unsermake with these new rules will break KDE packages unless the user does something like symlink the unsermake executable to /usr/bin (or somesuch). And, no, adding the path to unsermake to the PATH environment variable (from the command line) doesn't work -- I tried that. I didn't try adding the unsermake directory to /etc/env.d ... but none of this should be required as a manual step should it?
I don't we are able to support unsermake at the moment anyway, there are many problems with it (see bug 97428)... but everyone interested is free to provide some help with it!
> I don't we are able to support unsermake at the moment anyway, there are > many problems with it (see bug 97428)... but everyone interested is free > to provide some help with it! I don't mind if it isn't supported, but the ebuild shouldn't be trying to use it if it doesn't work. The main problem isn't so much that kipi-plugins doesn't work with unsermake, but that it doesn't work AND it tries to use it. Or to put it another way: the main problem is that kipi-plugins won't emerge if unsermake is merged.
