On Wed, Dec 10, 2008 at 11:27:54AM +0000, Enrico Zini wrote:
>   * [PATCH] gdalpaths.dpatch added to use the same plugins directory
>     used currently in gdal-grass. It would require a much better approach
>     upstream. See #2371 upstream bug. Also changed path for share dir path
>     to /usr/share/gdal15.
>     (closes: #481263)
> Now I'm trying to write autotools support to install a GDAL plugin into
> a system. Upstream documents the use of /usr/lib/gdalplugins, but after
> 1.5.1-4, Debian has diverged from that.  Now, I can only think of three
> ways to find out whether I should install to /usr/lib/gdalplugins or
> /usr/lib/gdal15plugins:
>  1. Test for which of the two directories exists.

This is the correct way to go. 

>  2. Mess around with dpkg, to see if I am in Debian and what version of
>     gdal is currently installed.
>  3. Use /usr/lib/gdalplugins unless overridden by a new ./configure
>     option (and therefore, leave it up to the user or the .deb
>     packager)
> So, basically Debian has now diverged from upstream in a nonstandard
> way, that requires all plugin install systems to have custom install
> procedures especially for Debian.
> Upstream has updated bug #2371 about this problem.

There's a good reason for that diversion: plugins solibs are not 
versioned. That implies (already happened) breakages at upgrade
time (basically new and old packages cannot cohexist) 
and big issues for the poor developer that developed plugins
for gdal independently. We could diverge using a versioned 
edition or use a different dir for each new source package.
Both strategies are suboptimal, so convince upstream to
adopt a sane versioning for plugins or introduce 
a new option to gdal-config to discover the plugin dir on-fly.
Maybe I already pointed that in the past, maybe not...

Francesco P. Lovergine

Pkg-grass-devel mailing list

Reply via email to