[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DebianGIS] Re: gdal



Hi Jon and all of you,

I am now back from vacation and would like to join the efforts to
build a good gdal package again :-)

On Wed, Dec 21, 2005 at 12:25:29AM -0500, Steve Halasz wrote:
> Jon,
> 
> On Mon, 2005-12-19 at 09:18 -0800, Jon Saints wrote:
> > Seems to me Its best for now to so ahead and put Steve's package with
> > my one change on alioth CVS into unstable. This will break other
> > packages qgis and mapserver.  But as of my tests last night neither
> > package was installable any way so our interference will be minimal.
> > At least in the long run we will have gdal 1.3.1 in unstable that we
> > can use to build new mapserver and qgis packages.
> 
> We'll need to rebuild everything that depends on gdal I think. But I
> still think it's worth uploading 1.3.1. I'm still not sure what the name
> of the library package should be. Based on more reading of the library
> packaging guide I don't think libgdal2 is good because the soname is
> still libgdal.so.1 and the name is supposed to match the soname. How
> about libgdal1.3.1-1? So the upload would be libgdal1.3.1-1-1. What
> could be more clear?

Since the soname is still libgdal.so.1 I don't understand why we
couldn't leave the package name as it is and just represent the new
release by increasing the package version. Thus the pacakge will be
named libgdal1c2a-1.3.1-1.

> 
> Steve
> 
> >  
> >  Once we have this version in unstable I will begin looking into
> > making a separate C++ library package that wont break qgis and
> > mapserver with updates.  

I read the thread about ABI/API changes in the C++ and C library. If
I understand it the right way, your suggestion means, that each time
a new release of gdal has been made all packages that depend on the
C++ library will have to be rebuild while those depending on the C
library will have no harm as long as the soname doesn't change.
Right?

In this case this seems to be a good idea to me. Of course this
means that at least mapserver and perhaps qgis will have to be
rebuild more often than it would be preferable but in midterm we
could perhaps bring the developers to adapt their sources.

Please let me know if I can help out. 

> >  
> >  Has anyone researched how other distrobutions are dealing with this
> > issue?

I don't think that other distributions have less problems with it. I
built the package for Fedora an until now I havn't been aware of
this problem so in conclusion this is not yet taken into account for
package building. 

For SUSE there is the LINGIS project but I think this project is
more or less in one hand.  Thus the targets are not that evolving as
this is the case for debian, Fedora-extras or other community driven
distributions.  Furthermore the release plan talks about a new
version in April 2005 which hasn't come yet - so far as I know. Please
correct me, if I am wrong.

I don't know anything about Mandrake.

Many greetings,

	Silke

-- 
Intevation GmbH

Georgstrasse 4                    49074 Osnabrück, Germany
http://intevation.de              http://intevation.de/~silke
FreeGIS.org                       http://freegis.org/

Attachment: signature.asc
Description: Digital signature


Reply to: