On 27 September 2014 at 20:44, Matt Dowle wrote: | | Hi, | | What I needed to do was : | | sudo apt-get install libgdal-dev libproj-dev | | Mind you, I'm on Linux Mint Debian Edition, so Ubuntu may be completely | different. I'm not sure. | | The trick seems to be searching for subsets of the package name; e.g.
12.04 is an old system, and Matthieu works with a backported *EXTERNAL* repo, ie packages via cran / the marutter PPA. That is harder to tighten. | $ apt-cache search gdal | dans-gdal-scripts - GDAL contributed tools by Geographic Information | Network of Alaska | gdal-bin - Geospatial Data Abstraction Library - Utility programs | libgdal-dev - Geospatial Data Abstraction Library - Development files | libgdal-doc - Documentation for the Geospatial Data Abstraction Library | libgdal-perl - Perl bindings to the Geospatial Data Abstraction Library | libgdal-ruby - Ruby bindings to the Geospatial Data Abstraction Library | libgdal-ruby1.8 - Ruby 1.8 bindings to the Geospatial Data Abstraction | Library | libgdal1 - Geospatial Data Abstraction Library | libgdal1-dev - Geospatial Data Abstraction Library - Development files | python-gdal - Python bindings to the Geospatial Data Abstraction Library | libgdal1-1.9.0-grass - GRASS extension for the GDAL library | qlandkartegt - GPS mapping (GeoTiff and vector) and GPSr management | | See what that returns for you and just keep installing likely candidates | until it works. That's what I do. It sometimes seems to be the ones You can be a little more scientific / engineering mindes and *SEE WHERE THE BUILD BREAKS* which configure and gcc will tell you: generally 'foo.h not found'. Then use packages.debian.org [ or equivalent at Ubuntu etc pp ] to search for the package supplying foo.h, install that package and try again. That usually does it. Now, a binary package such as r-cran-gdal should of course have working dependencies. But for an external backport (see above) fewer checks and balances exist. | ending -dev (or similar) that are needed. Even though we aren't | "developing" such packages for R I suppose because we need to install | from source on Linux, in a sense we are. | | I seem to remember that package needs libproj-dev as well, which is why | I included it above. May be wrong on that. | | What beats me is why the Linux package dependencies aren't included in | the package DESCRIPTION file. I guess that's because they're different | names on each distro (again, something else that puzzles me)? So then I | wonder why not include dependencies for the common distros like Ubuntu | and Debian derivatives: that'd be a start. I look forward to you launching and spear-heading such an effort. After all, you *only* need to coordinate with maybe ~ 1000 different CRAN authors, check over maybe six or seven different flavors and distros, keep track of library renamings when they happen (libfoo3 -> libfoo4) (but keep those seperate for different release flavours of your seven target distros), construct a bulk checking mechanism etc pp. Of course this is "trivial" to do "in theory". Hoever, "in practice" it is a metric fuckton of work which is why we all have been waiting for you to warm up to it. ;-) Seriously, people talked about doing this for RH/FC when we first managed a proof via cran2deb (mind you: one target distro, one release) and could not even get that one other target distro going.... It's simply a hard problem. | Still, much better than Windows. Well that is an admiringly low bar to clear... Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | [email protected] _______________________________________________ R-SIG-Debian mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-debian
