When using stow to install something that wants to put some libs in /usr/local/lib stow will fail with something like this: CONFLICT: /usr/local/stow/dmtcp/lib vs. /usr/local/lib because /usr/local/lib is a symlink pointing to /usr/local/lib64 (so it's not "owned" by stow). A possible workaround would be to move stow/$PACKAGE/lib to stow/$PACKAGE/lib64. Once installed the package will not notice the difference as lib points to lib64...
I don't feel that this issue is with Stow per se, but rather with the users. Instead of throwing app-admin/stow out, I propose that we encourage users to use /usr/stowed/stow instead of /usr/local/stow as their stowdir. If you don't like /usr/stowed, we could use /opt/stow. A small change to the environment is needed to accomodate a non-traditional stow dir. Here's my /etc/env.d/10stow: LDPATH="/usr/stowed/lib" PATH="/usr/stowed/bin" The point is, Stow isn't broken. It nicely meets the need for users who want to quickly add a package to their system but who don't want to maintain an ebuild for it. Let's not get rid of it so hastily. If it takes someone being stow's maintainer to save it, then I'll do it. Tell me where to sign up.
Stow has no maintainer. If you are interested in fixing the package have a look here http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml
Erik Falor is going to maintain this through me, so no more maintainer-needed. Patch for bug will be in tree later this week.
Any progress on that?
I've submitted a patch to Maxim Koltsov, and we've gone back and forth on a few details. We should have a final commit very soon.
There's a 2.1.0 version out as of today.
Thanks for the heads-up, Jeroen. I'll prepare a new ebuild.
Attempted to write an ebuild for Stow-2.1.0, but ran into a configure script problem. Awaiting response from upstream.
Okay, fixed finnaly, old version & new version. Thanks, Erik.
