packaging gdal for debian

[paulbaker78]

--- In gdal-dev at y..., "Timothy H. Keitt" <tklistaddr at k...> wrote:
> In terms of Debian, we should probably be looking at how other
packages
> handle python, shared libraries, etc. It would be great to make the
> build process as compatible as possible with dh_
make/dpkg-buildpackage
> so that packaging could be largely automated.

Yes I was planning to look into that very soon as well, as mapserver
includes the mapscript/python support, so I need to figure out how to
package that up for debian as part of my mapserver packages. Whatever
I learn for that will apply to my gdal packages I'm sure.

> I second the idea of having a sourceforge-like packaging project
with a
> separate email list. With ftp/http access, we can make a small
Debian
> apt-getable archive.

Currently, you can sorta find that my package archive. Just add these
to /etc/apt/sources.list

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

Right now though it only includes my mapserver ang gdal packages. I
would not call them ready for primetime yet since I'm not sure my
mapserver build works yet, and my gdal packages break debian policy
(which is what this whole thread is about as you know). But anyone who
wants to take a look I'm more than begging you too. ;-)

I'm also currently looking for a debian sponsor to get these included
officially into debian until I can become a full-fledged official
developer. Someone on the debian-mentors list pointed me to someone
who has been packaging GRASS and other GIS related packages. I'll try
to get in touch with him to see if he wants to work together.

> On Fri, 2002-06-07 at 00:26, Frank Warmerdam wrote:
> > 
> > Paul,
> > 
> > I'm not sure why you say that GDAL doesn't build a shared
library. I
> > assume you mean it doesn't produce a shared library with the usual
> > naming conventions. Is that right?

Actually after I sent my email and then keep looking at things I came
to the conclusion that it is building a shared library, just not to
conventions.

> > After soon initial hesitancy, I am now willing to revise how I
build the
> > shared library to conform when conventions. I won't use libtool
for reasons
> > I have tried to explain before, but I am willing to modify the
configure
> > scripts to build with conventional names, and using -soname and so
forth
> > set things right.

I have no personal attachment to libtool, so this sounds good to me.

> > Hopefully we can roll this out as a GDAL 1.1.8 release in the
relatively
> > near future.

That would be great.

> > Before I go digging for more details tomorrow, can anyone point me
to what
> > I should be using as a link command on Linux?

I will ask around on debian-devel and see if anyone has some advice. I
don't know if this helps, but this is the link to the unofficial
library packaging guide for debian:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

> > Also, on the issue of having the separate development package. I
am also
> > willing to separate out an install-slib, install-dev, install-bin
and
> > install-all targets which would do:

The way the debian packaging system works, this wouldn't really be
necessary, but if you want to go ahead. :-)

> > I am also willing to review how GDAL installs figure out where to
put python.

As I said above I'm going to be looking into this today, so I'll let
you know.

> > PPS. I would love to see a centralized package of gis/rs related
debs accumulated
> > somewhere like remotesensing.org. I can provide system access if
this is felt to
> > be a good idea. Does it make sense to do the same thing for rpms
or should we
> > leave this to the freegis guys who are already producing rpms for
the freegis CDs
> > anyways? Is there a redhat/rpm equilvelent to apt-get and co?

This sounds like a great idea, since the webserver I'm currently
housing paulbaker.net on may be going down by the end of the month, I
don't know how stable my package repository is going to be. As far as
RPMs I have no comment on that.

> > PPPS. I think we should have a mailing list or something for
discussions of packaging
> > of gis/rs related packages for debian. To avoid duplication, and
to ensure that the
> > various related technologies (GRASS, MapServer, PROJ.4, GDAL,
OpenEV) can work together
> > properly.

I think I'll ask on debian-devel if they would be willing to set up a
debian-gis mailing list. They probably would as Debian + GIS seems to
be picking up more and more steam.