ignoring shebangs

[Cameron Scott ICM N MC MI SI 6 <Scott Cameron icn siemens de>]

Greetings.
I've got troubles again :)

Some files the developers have generated have shebangs pointing to various
paths on their boxes for various applications.
RPM sees these as dependencies when I build the package and therefore won't
let me install the .rpm even though I've got these applications installed in
another place.

Of course, this is a development error and needs to be fixed / thought-over.
Unfortunately, development (one guy) is currently on vacation - hence my
sudden ...how you say pickle?
Note I don't have the option of removing these binaries from my files-list -
they are all required.

Is there any way to have RPM ignore shebangs as dependencies?
I don't want to disable RPMs automatic dependency checking (AutoReqProv: no)
- just this one shebang part of it.


Perhaps I'm asking too much :)


*********************************************
Another related question...
What, in your expert opinions, should the philosophy of the use of shebangs
be?

small example:

A source Perl script of an application uses: #!/usr/bin/perl
For sure, a requirement of this application should be perl (version
whatever) but should it really be /usr/bin/perl specifically?

If perl was installed in /usr/local/bin/, I could make a softlink so that it
looks like perl is installed in /usr/bin/ but for that I'd need write
permissions.
Problem 1.
Second problem may be that another perl script uses #!/usr/local/myperl/.
Now I have 2 softlinks to make. etc.

Should we force development to use one specific path to their perl?  If so,
there goes the idea of having a relocatable perl installation.
Note:  Perl is just an example here - could be anything.

Should the developer just assume that perl is in the PATH variable?  Perhaps
this is best solution but then you have to worry about modifying PATH
variables and if the rpm is installed as root, so much for that being
automated.
Should we (I) make a post-install script that will modify the shebangs?
(Doesn't help my initial dependency problem)

Any ideas on this?  What's your organizations process?


TIA,
Cheers,
Scotty