I have dropped the following keywords from gentoolkit-0.3.0_rc8 due to the runtime dependency on app-misc/realpath for revdep-rebuild: ~m68k ~s390 ~sh ~sparc-fbsd ~x86-fbsd m68k/s390/sh: Can you please test and keyword app-misc/realpath with revdep-rebuild and re-keyword gentoolkit-0.3.0_rc8? bsd: Can you please verify that revdep-rebuild works with the realpath binary in freebsd-bin, so that we can make the appropriate dependency changes and re-keyword gentoolkit-0.3.0_rc8?
We are also going to need this for gentoolkit-0.2.4.6 which is gentoolkit-0.2.4.5 with all fixes to revdep-rebuild from the gentoolkit-0.3.0 series backported.
How does it use realpath, and why can't it use `readlink -f' (coreutils) instead?
readlink -f and realpath have slightly different semantics, and readlink -f is not compatible with non-GNU systems.
Yes, I gathered as much, but with slightly more complicated code (I think it's only used in revdep-rebuild anyway) to check whether to use either realpath or readlink, an RDEPEND could be dropped for everything GNU. Want another bug opened with perhaps a patch?
I'm always open to patches and suggestions. Personally, I liked realpath because it is compatible to non-GNU systems. But if ongoing maintenance and architecture keywording/stabilization will be easier by using readlink -f, then let's go that route. My only concern with changing it right now is that the realpath changes have been tested fairly well on the gentoolkit-0.3.0 series and I would like to request 0.2.4.6 stable as soon as it hits 30 days in tree. The revdep-rebuild in 0.2.4.5 is going to start causing major problems as some of the packages currently in ~arch start going stable. However, since realpath isn't keyworded on the architectures CC'ed in this bug, for them that is a moot point and we could target 0.2.4.7 with readlink -f/realpath for those architectures.
~m68k/~s390/~sh done
seems fine with realpath from fbsd-bin, dep adjusted and keyworded *-fbsd -> fixed
