This is not specifically a CentOS question, but I am creating RPMS for CentOS 6 from some CRAN tarballs. 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. Is there a option to not create the dependency? Thanks Tony Schreiner
If I may add The created spec file does not list the dependency on /usr/bin/r, something in rpmbuild creates it. On Wed, Jun 3, 2015 at 3:49 PM, Tony Schreiner <anthony.schreiner at bc.edu> wrote:> This is not specifically a CentOS question, but I am creating RPMS for > CentOS 6 from some CRAN tarballs. > > 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. > > Is there a option to not create the dependency? > > Thanks > Tony Schreiner >
Am 03.06.2015 um 21:49 schrieb Tony Schreiner <anthony.schreiner at bc.edu>:> 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. > > Is there a option to not create the dependency?can't test it here right now - but try adding following line at the top of your spec file: %define __os_install_post %{nil} -- LF
Thanks for the suggestion, but after putting that at the top of the spec
and running rpmbuild, I still get
Resolving Dependencies
--> Running transaction check
---> Package R-RPostgreSQL.x86_64 0:0.4-1.el6 will be installed
--> Processing Dependency: /usr/bin/r for package:
R-RPostgreSQL-0.4-1.el6.x86_64
--> Processing Dependency: /usr/bin/r for package:
R-RPostgreSQL-0.4-1.el6.x86_64
--> Finished Dependency ResolutionError: Package:
R-RPostgreSQL-0.4-1.el6.x86_64 (/R-RPostgreSQL-0.4-1.el6.x86_64)
Requires: /usr/bin/r
when trying to install the resulting RPM
and
$ rpm -qp --requires ../RPMS/x86_64/R-RPostgreSQL-0.4-1.el6.x86_64.rpm
/bin/bash
/usr/bin/env
/usr/bin/r
R-DBI
R-methods
libR.so()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libpq.so.5()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1
On Thu, Jun 4, 2015 at 5:47 AM, Leon Fauster <leonfauster at
googlemail.com>
wrote:
> Am 03.06.2015 um 21:49 schrieb Tony Schreiner <anthony.schreiner at
bc.edu>:
> > 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.
> >
> > Is there a option to not create the dependency?
>
>
> can't test it here right now - but try adding
> following line at the top of your spec file:
>
> %define __os_install_post %{nil}
>
> --
> LF
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
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
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
On 6/5/2015 3:09 AM, Peter 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/*.RI assume the "unless $i++" is supposed to limit the replace operation to only the first line each file. Unfortunately, since it is a global variable, it is actually limiting it to only the first line of the first file. I'm not sure how you would fix this using the -p option. You would probably have to write out the loop manually in order to localize the variable properly. -- Bowie