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

Re: Package name



On Sat, May 21, 2005 at 01:16:57PM +0300, Shachar Shemesh wrote:
> Steve Langasek wrote:

> >>I have still not totally given up on convincing him, though, so I'll be 
> >>in touch.... :-)

> >It's not acceptable to install a shared library without an SONAME for two
> >reasons:

> >- if the library's ABI changes and the filename doesn't change, the new
> > library package will have to conflict with the old package, forcing
> > removal of all other packages using the old version of the library
> >- if at a later date upstream comes to their senses and starts using an
> > SONAME for their shared library, the *-dev* package will still have to
> > conflict with the old library package for the same reason, forcing removal
> > of packages depending on it

> But if I do introduce SONAME to the Debian version, what version should 
> it have? The only sensible answer that I can think of is "0", as any 
> other answer is sure to conflict with the upstream choice, should they 
> come to their senses in the future. I don't see the major difference 
> between saying "SONAME" version 0 and not giving SONAME at all, but I 
> don't mind it so much either.

An so version of 0 is the simple so version least likely to conflict with
upstream's versioning in the future.  If you're worried that you may have to
go through ABI changes on your own before upstream gets around to the whole
sanity thing, then it's probably best to use a Debian-specific so versioning
scheme: e.g, libargtable2.so.0debian0, libargtable2.so.0debian1, etc.  You
can find examples of such library package names in the archive.

> >Introducing an SONAME to a library in Debian when it doesn't have one
> >upstream isn't great, but the only sensible alternative is to not ship it 
> >as
> >a shared library at all.

> Another thing that comes up is an incompatibility between the deb 
> currently provided by the site (as well as binaries compiled with 
> libargtable compiled from source) and the deb we would provide. Binaries 
> compiled with the former two will depend on "libargtable2.so", while 
> binaries compiled with the later will depend on "libargtable2.so.0". I 
> can fix it by including the symlink from libargtable2.so to 
> libargtable2.so.0 in the non-dev package, I think. Will it work?

If you include that symlink in the non-dev package, you have the same
problem as before with packages needing to conflict with one another.  That
being the case, I don't think you have any responsibility to work around
upstream's broken .debs in your Debian packages.

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: