[gdal-dev] packaging gdal for debian

Timothy H. Keitt tklistaddr at k...
Fri Jun 7 08:43:24 EDT 2002


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.

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.

Tim

On Fri, 2002-06-07 at 00:26, Frank Warmerdam wrote:
> 
> paulbaker78 wrote:
> > 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.
> 
> 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?
> 
> 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.
> 
> Hopefully we can roll this out as a GDAL 1.1.8 release in the relatively
> near future.
> 
> Before I go digging for more details tomorrow, can anyone point me to what
> I should be using as a link command on Linux?
> 
> 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:
> 
> install-slib: Just installs libgdal.so.1.x and support shared data.
> 
> install-bin: Installs various programs, and requires install-slib.
> 
> install-lib: Installs static library and include files.
> 
> install-all: Does all of the above.
> 
> I am also willing to review how GDAL installs figure out where to put python.
> Currently I used a bunch of custom configure logic to find where python modules
> belong, and try to install there. Often somewhere like /usr/lib/python2.0/site-packages.
> This gets put in the INST_PYMOD macro in GDALmake.opt, which can be overridden
> on the make commandline if need be. But there have been complaints that I don't
> honour --prefix settings for the python install. The problem is that the python
> modules can't work if they aren't installed where python is, unless people extend
> their PYTHONPATH or something. So what exactly do people want, and how will it
> produce a useful install tree?
> 
> PS. I run debian, but generally hesitate to install .debs for stuff like PROJ.4
> and GDAL for fear of confusing my local working configuration. I already have
> problems from having an installed copy of stuff in /usr/local and my local builds
> at times. I suppose I ought to setup an alternate bootable root on my system for
> testing stuff like this.
> 
> 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?
> 
> 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.
> 
> Best regards,
> 
> -- 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at p...
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush | Geospatial Programmer for Rent
> 
> 
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 





More information about the Gdal-dev mailing list