osx packaging: issues with fixlib() in osx-app.sh

current issues with fixlib() in 'packaging/macosx/osx-app.sh' when building the application package from current bzr trunk (r9145):

1) fails if not run with 'sudo' rights because OpenSSL libs are installed with limited permissions ('r-xr-xr-x') in MacPorts (libcrypto.0.9.8.dylib, libz.1.dylib)

2) fails if custom MacPorts tree is installed in user account or on (mounted) partition (i.e. custom MacPorts prefix has more than 2 dir levels).
 works with: /opt/local-macports-with-a-really-very-quite-long-directory-name
 fails with: /Volumes/blue/mp-inkscape/with-a-long-long-long-directory-name
due to hard-coded level of directories (using e.g. "relative=`echo $lib | cut -d/ -f4-`")

3) redundant second-level 'for'-loop: rewrites paths of all linked dylibs that had been copied to 'Contents/Resources/lib' every time a linking *.so executable is changed (i.e. all linked dylibs are touched over and over again - but they are parsed at the end of rewritelibpaths() anyway, so this second-level loop is not needed AFAIU)

4) incorrect id of many 'Contents/Resources/lib/*.dylib' executables: because id change is part of the first level 'for'-loop for the linked dylibs and not for the current lib, every loop incorrectly sets the install name of the linked lib to the name of the linking lib.
Do we really need to change the install name at all? AFAIU it is only required when a dynamic library is linked into another executable.

Mac OS X 10.5.8
Inkscape 0.47+devel r9145
MacPorts 1.8.99 (trunk)