[R-sig-Debian] r-cran-rgdal: dependency on libgdal1 unsatisfied in ubuntu 12.04?

[Dirk Eddelbuettel]

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 | edd at debian.org