Re: [DebianGIS] libgdal renaming
"I think if the source package stops producing a particular binary package the ftpmasters end
up removing it."
Does anyone know if this is the case?
Thanks
Jon
----- Original Message ----
From: Steve Halasz <debian@adkgis.org>
To: pkg-grass-general@lists.alioth.debian.org
Sent: Mon 09 Jan 2006 02:44:38 PM MST
Subject: Re: [DebianGIS] libgdal renaming
On Mon, 2006-01-09 at 14:43 +0100, Silke Reimer wrote:
> On Mon, Jan 09, 2006 at 02:02:01PM +0100, Francesco P. Lovergine wrote:
> > On Mon, Jan 09, 2006 at 07:09:48AM -0500, Frank Warmerdam wrote:
> > > On 1/7/06, Silke Reimer <Silke.Reimer@intevation.de> wrote:
> > > > I would vote to stick to our decission about the package name but adapt
> > > > the soname of libgdal to have an minor and subversion, so that the full
> > > > soname is 1.3.1 instead of 1. This will have the advantage that there
> > > > isn't any need to rebuild qgis or other package just because a new gdal
> > > > version is present since its concurrent installation on the same system
> > > > is possible.
> > > >
> > > > It requires though that Frank changes the soname each time he releases a
> > > > new gdal version - which isn't too difficult I think. So we need some
> > > > feedback from you, Frank.
> > >
> > > Silke,
> > >
> > > I am not adverse to the soname changing for each version
> > > on Debian, but I think that should be a debian specific
> > > patch, not something done upstream.
> > >
> > > For my purposes (in the general context) the soname and
> > > versioning are about the C API, not the C++ API, and that
> > > is why I don't want to change this upstream. I do realize that
> > > for the sake of proper version selection re: MapServer and QGIS
> > > you need distinct libraries as the C++ ABI alters but I don't
> > > wish to do that in general for GDAL.
>
> OK. We have to accept this though we will have the same problem
> with other distributions as well (as Fedora for example where
> gdal is not far from being accepted for Fedora Extra).
>
> Since I am not keen to use sonames on a system that are not
> supported by upstream I vote for renaming the library itself:
>
> instead of libgdal.so we should have libgdal<gdalversion>.so
>
> This would require to patch mapserver, qgis etc. so that they
> link against libgdal<gdalversion> instead of libgdal.
>
> The package name should be
> libgdal1-<gdalversion> resp. libgdal1-<gdalversion>-dev as we
> already decided last week.
Will it be necessary to change the source package name to facilitate
concurrent installs of different gdal versions? I think if the source
package stops producing a particular binary package the ftpmasters end
up removing it.
>
> What do you think?
>
> > >
> >
> > Why not splitting C and C++ libs?
>
> As far as I understood we all agreed that this would be a good
> solution but is something for midterm because right now there
> isn't anybody who has enough time to actually do it. In my
> opinion it would be the better solutions though.
This would be the ideal long-term solution. Unfortunately, Frank just
said that this is impossible because the C and C++ methods are in the
same source files. I don't want to undertake it if he's not willing to.
Steve
_______________________________________________
Pkg-grass-general mailing list
Pkg-grass-general@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-general
Reply to: