On Fri, Jun 5, 2015 at 3:09 AM, Peter <peter at pajamian.dhs.org> wrote: > On 06/04/2015 07:49 AM, Tony Schreiner wrote: > > I run R2spec -s tarball to create a spec file, and most of the time it > > works ok, but sometimes (RPostgresSQL, Rcpp for example) the package has > > test or example programs that start with > > > > #!/usr/bin/r > > > > with lower case r, and the resulting package then winds up with a > > dependency on /usr/bin/r, which can't be resolved. > > > > So far I have solved it by editing all the files and replacing with > > /usr/bin/R, recreating the tarball and going through the process again, > but > > I have to believe there is an easier way. > > Kind of. This is an obvious error in the packaged scripts in the > tarballs. I generally don't recommend modifying the original tarball as > I like it to be a true representation of the tarball source that you get > from upstream. What I do instead is patch it in the spec file. > > In this case it would probably be easier to do one line of perl or awk > that patches the shebang line in all the scripts at build time than it > would be to generate individual patch files for each source tarball. > You would add this to the %prep stage of the spec files, something like > this after the initial %setup macro: > > perl -pi -e 's:^#!/usr/bin/r:#!/usr/bin/R: unless $i++' > path/to/R/scripts/*.R > > > Peter > _______________________________________________ > Peter and Leon The %define __find_requires %{nil} sounds too disruptive. I'll look at scripting the corrections. Maybe I will request at EPEL to see they would consider making a link to /usr/bin/r. However I checked a Debian installation, and it's not there either. So I don't know what the creators of the CRAN package are targeting. Thanks again Tony