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
_______________________________________________
Rpm-list mailing list
Rpm-...@redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list
> From: Cameron Scott ICM N MC MI SI 6 <Scott....@icn.siemens.de>
> Date: Wed, 18 Jul 2001 16:24:36 +0200
>
> What, in your expert opinions, should the philosophy of the use of shebangs
> be?
Either your organization needs to agree on the location of interpreters like
perl or your installation process (./configure?) needs to figure out where the
interpreters are and put them in the shebang lines before creating the RPM.
There's really no other way around this with the possible, but stupid solution
of creating an RPM which contains and provides all the random links for the
interpreters.
Just one humble opinion.
Chris
--
Chris Garrigues http://www.DeepEddy.Com/~cwg/
virCIO http://www.virCIO.Com
4314 Avenue C
Austin, TX 78751-3709 +1 512 374 0500
My email address is an experiment in SPAM elimination. For an
explanation of what we're doing, see http://www.DeepEddy.Com/tms.html
Nobody ever got fired for buying Microsoft,
but they could get fired for relying on Microsoft.
--==_Exmh_-1513455304P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.2_20000822 06/23/2000
iD8DBQE7VZ5UK9b4h5R0IUIRAkKcAKCG7Etl2tzqFsQS2czDAi5msBs6lQCbBHEf
MRVcQJ2yUNiDEM7sAMiUEXg=
=yuvc
-----END PGP SIGNATURE-----
--==_Exmh_-1513455304P--
Quick answer:
Apply patch to package to fix the shebang.
This is the Right Thing To Do.
Short answer:
chmod -x $RPM_BUILD_ROOT/path/to/file/with/shebang
rpm does not look at non-executable files when generating dependencies.
Longer answer:
Roll your own Requires: filter as
#!/bin/sh
/usr/lib/rpm/find-requires | sed -e 's/bad_interpreter//'
Put the 1 liner above someplace like /etc/rpm/find-requires.
Enable by adding to spec file
%define _find_requires /etc/rpm/find-requires
or by configuring per-system
echo "%_find_requires /etc/rpm/find-requires" >> /etc/rpm/macros
Red Hat just puts the interpreters in predictable places that can be used
in scripts reliably ;-|
73 de Jeff
--
Jeff Johnson ARS N3NPQ
j...@jbj.org (j...@redhat.com)
Chapel Hill, NC