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

Re: libopenobex library transition

On Thu, Mar 23, 2006 at 05:16:55PM +0100, Hendrik Sattler wrote:
> Am Donnerstag, 23. März 2006 06:36 schrieb Steve Langasek:
> > On Wed, Mar 22, 2006 at 04:55:39PM +0100, Hendrik Sattler wrote:
> > > Sadly, they changed the soname again. So instead of directly uploading
> > > the new upstream version, I would like to wait for the following bugs to
> > > be resolved,
> > > first:
> > > affix: #358279
> > > kdebluetooth: #358275
> > > multisync: #358283
> > > obexftp: needs upload of 0.19 (have to ask my sponsor :)

> > First of all, why are there already two libopenobex packages in unstable
> > (libopenobex -> libopenobex1, and libopenobex1.0 -> libopenobex1.0-0)?

> > Secondly, why do the above bugs need to be fixed before uploading the new
> > version of libopenobex?  AIUI, they already build-depend only on
> > libopenobex-1.0-0-dev, which is the older version of the library.

> Right.

> > Third, if you're changing the name of the -dev package anyway, why are you
> > changing it to libopenobex1-dev instead of libopenobex-dev?  Is the API
> > expected to change with every soname change?

> No but I cannot say that it will never change in an incompatible way (be it 
> renaming of structs, functions, the whole glue or how the library can be 
> detected).
> I followed libpkg-guide here:
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id265760

Yes, please don't follow that recommendation; there's nothing "ideal" about
putting sonames in the -dev package names -- having such -dev packages
Provide: libpackage-dev is better than nothing, but again it still gives
problems if you need to add a versioned build-dep as in this case.

Junichi's library packaging guide is indeed pretty good for the most part,
but this particular recommendation is a bad one.

> Additionally, libopenobex-1.0-0-dev already has a
> Provides: libopenobex-dev
> which makes this impossible (could stay installed in this case).

If all packages are supposed to build-depend on libopenobex-dev (>=
$version), then it's again not an issue.

> > > When those are in testing, I will request removal of the old binary lib
> > > packages (libopenobex-1.0-0*) from testing and sid.

> > Well, that answers my first question.  It also means that those bugs are
> > filed at the wrong severity: these packages currently do *not* FTBFS,
> > because you haven't requested removal of the old library yet.

> BTW: do they get removed automatically after some time or do I have to request 
> that? What about the source packages?

I gather that this was addressed in a previous message.

> > > The build dependencies of those packages should then be at
> > > libopenobex-dev (>= 1.1)
> >
> > That won't work.  libopenobex-dev is a virtual package; you can't have a
> > versioned (build-)dep on a virtual package.

> Ui, didn't know that. Then it must follow every soname manually...

No, there's no reason *at all* to change -dev package names in conjunction
with soname changes.  You might consider it worthwhile to change -dev
package names when the API changes incompatibly, but that's not the same
thing as an soname chnage.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: