> Well, yeah, but... where the executable is ought, honestly, to be > irrelevant. If I've stuck Parrot in /usr/bin it seems unlikely that > I'll have parrot's library files hanging off of /usr/bin.
Bah. BAH, I say. The /usr/bin/parrot is of course a symlink to, say, /platform/os/version/parrot/version/bin/parrot, and we parse the real path, not the symlink. > And if I've got a few hundred machines with parrot's library NFS mounted in > different places (to match conflicting vendor standards and other > whackjob breakage which is endemic in, well, the world) it really > falls down. :) Add to that you can't always figure out where Parrot > really is both because of chroot behaviour and some odd "where am I > really" problems with suid scripts in some places. > > There are a couple of folks who could make your brain melt and flow > out your ears with all this stuff too. Yes, I was once one of those people :-) > Having the executable path as an optional way to get the info's not > necessarily a bad thing, but I think it's safe to say that it's not > The Right Thing. (If there even is one) > > If nothing else this has convinced me we need a way to specify site > policy at build time for all this nonsense^Wfun. :)
