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. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
