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

Re: [DebianGIS] gdal package names?



On Wed, Jan 04, 2006 at 03:48:15PM +0100, Francesco Paolo Lovergine wrote:
> On Wed, Jan 04, 2006 at 09:34:08AM -0500, Steve Halasz wrote:
> > I committed the name change in CVS. The -1 refers to the SONAME rather
> > than the debian version. So the first upload would be
> > libgdal1.3.1-1_1.3.1-1, the second libgdal1.3.1-1_1.3.1-2 and so on.
> > This is based on the library packaging guide which says:
> > 
> > "To distinguish the package name and the SONAME version number, for
> > library packages with a name ending in a numeric, the form
> > lib[libraryname]-[SONAME version number] is preferred."
> > 
> > Although the library name doesn't really end in a numeric I was trying
> > to go for something as close to accepted policy as possible.
> > 
> > The policy manual states that the package name must change. This is to
> > force all depending packages to rebuild for the new ABI. Am I wrong
> > here? Is there another way to make this happen and conform to policy?
> > 
> > I'm not in favor of changing the SONAME ourselves since it would be
> > inconsistent with the actual SONAME which will hopefully be updated
> > correctly in the future.
> > 
> > Also I've asked about this on the mentors list and somebody said they
> > thought, given the situation, that putting the version number in the
> > package name "seems ok":
> > http://lists.debian.org/debian-mentors/2005/12/msg00282.html
> > 
> 
> On the basis of Steve and Silke comments, it seems reasonable for
> me using something like
> 
> libgdal1-1.3.1
> libgdal1-1.3.1-dev
> 
> the reason is that the soname is already present in the first part.
> Repeating that is perfectly superfluos. I think honestly that the minor
> version could be also neglected and added again just in case it would
> be useful later. So 
> 
> libgdal1-1.3
> libgdal1-1.3-dev
> 
> could suffices.

Seems to be a reasonable solution to me. Whether we could suppress the
minor version is something Frank could answer best I believe since it
depends on the questions whether there will be ABI changes between two
minor versions.

> 
> The reason for having the versioned -dev package
> is managing possible C++ API changes consistentl (else libgdal1-dev
> would be ok). Using a simple counter instead of the version after
> the soname number could also be possible, but I would hope upstream
> will change the soname whenever the C++ interface stabilized, and
> we should get finally a libgal2 that day!

Yes, I hope so as well!

	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: