Re: [DebianGIS] Re: Re: gdal
On Tue, 2005-12-20 at 19:45 -0500, F.Sluiter wrote:
> Hi Folks,
>
> >Jon:
> >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.
>
> Are those the only packages that will break? I might be mistaken, but
> I think there are ocatve and R bindings for gdal, and most likely
> others.
> Is there an easy way to find out which packages are depending on gdal
> (m.i. C++ ABI)?
>
> > Frank:
> > Even 1.2.0 to 1.2.1 are likey to be ABI incompatible at the
> > C++ level.
> Sad but very true in many applications, a fact I overlooked in my
> previous post (sorry): The c++ template sufered badly form this some
> years ago and broke many many applications in the process.
>
> Is there a relatively stable version (most bugs fixed ;-) and 'fully
> functional' as well) that could serve as the officia debianl ' mostly'
> stable version and at the same time can be used to compile
> grass/qgis/mapserver etc?
>
> In that case Frank can satisfy his customers ad lib. and the packages
> could ultimatly reach their final nirvana (stable ;-) ) . After a
> couple of months (when Frank reaches a real version update), all
> packages could get their own packaged version update again.
>
> With my personal bias:
> It is very nice to be bleeding edge on our private machines, however
> some people need a 'semi' stable environment on their servers. As a
> side effect of gis availability on debian, allthough I protested
> vehemently, my production environment will be fedora (which also means
> I have to compile some tools from source since they are not available
> as rpm... <sigh>).
>
> So bottomline:
> Is it possible to 'freeze' gdal at this time to a certain version and
> get debian on GIS ? It seems that Gdal is [one of the core | THE]
> package for debianGIS.
I like this idea. We can upload 1.3.1 and then hold out for a while.
More long term I like the idea of separate packages for the C and C++
APIs. Geos is proposing to split like so:
Release version: GEOS-3.0.0 (new versioning scheme)
C lib soname: libgeos_c.so.1 (compatible with GEOS-2.2.x)
C++ lib soname: libgeos.so.3.0.0 (compatible with itself)
If they are provided by the same source package there would probably
still be some sticky issues. But it might be possible to limit the pain
to the packages that use the C++ API this way.
Steve
Reply to: