packaging gdal for debian

[paulbaker78]

I saw in the 'RPMs for Mandrake 8.2 and cooker' thread that there are
actually a couple other people trying to package gdal for Debian. I am
working on packaging it because I am also attempting to package
MapServer for Debian.

Right now you can check out the packages I've built by adding to your
/etc/apt/sources.list file:

deb http://paulbaker.net/debian pbaker main
deb-src http://paulbaker.net/debian pbaker main

Right now gdal is built as a single package called
gdal_1.1.7-1_i386.deb. This package contains everything that is
normally built by gdal. The problem with this, is that this package is
not compliant with Debian Policy and in it's current state could never
be included in Debian. 

Debian Policy
(http://www.debian.org/doc/debian-policy/ch-files.html#s11.2) requires
that all libraries in debian must produce at least 2 packages. There
must be a 'libpackagename' package (in this case it would be libgdal)
that contains the SHARED version of the library. The second package is
'libpackagename-dev' (in this case it would be libgdal-dev) that
contains the STATIC version of the library along with the .h files
etc.

The problem is that gdal upstream does not build a shared library. I
don't really have much experience with building libraries, so I'm not
really sure quite what to do in order to make this happen. The
combination of GNUMakefile and GDALMake.opt.in is not quite what I'm
used to seeing. In GNUMakefile there is commented out near the top
about using the commented out command instead of the one above in
order to build a "proper SO files that will work in /usr/lib". This is
of course what I need, but using that command instead of the upstream
one doesn't seem to quite pull it off. The suggested command gives
'-soname,gdal.so.1'. It really should be '-soname,libgdal.so.1' if I'm
not mistaking. And besides the actual file that is created is
libgdal.1.1.so which doesn't match either gdal.so.1 or libgdal.so.1.

Before each distribution starts packaging up gdal in different ways
with different sonames which will then completely break binary
compatibility with programs trying to work with the shared library
version from one distribution to another, upstream needs to hurry up
and spell out just how it's going to be.

Frank, if you are reading this, how open are you to working on getting
real shared library build targets included in the upstream source? I
hope you are willing before it is too late.

I'm also curious to hear what anyone else trying to package gdal up
has done towards this problem or if you are even aware of the
situation.