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

Re: RFC: libprojectM, new upstream version.



On Thu, 2008-07-17 at 00:57 +0200, Francesco Namuri wrote:
> Il giorno mer, 16/07/2008 alle 17.46 -0500, William Pitcock ha scritto:
> > Hi,
> > 
> > On Wed, 2008-07-16 at 22:59 +0200, Francesco Namuri wrote:
> > > Hi,
> > > I've packaged the new version of this library, the upstream author has
> > > changed the SONAME, and so I've changed the name of the lib and -data
> > > package, not changed the name of the -dev file because the old
> > > maintainer has chosen to not version the package.
> > > 
> > > This is my first library package, and I've some doubts, is for this that
> > > I'm asking for RFC...
> > > 
> > > Is it correct to replace the old library? This can cause some breakage
> > > with old linked binaries (if any, I've seen that no package depends on
> > > this library)...
> > 
> > audacious-plugins
> > libvisual-projectm
> > 
> > You will have to at least update audacious-plugins to work before doing
> > this.
> 
> ok,
> but about the name of the binary library package, is much correct to add
> the SONAME in the name of the package libprojectm2_1.2.0-1_i386.deb that
> replaces libprojectm1_1.01.0-1_i386.deb for example? or, considering
> that it is a small library a generic libprojectm_1.2.0-1_i386.deb?

Debian policy requires that it be named libprojectm2. Please be sure to
read the policy manual before continuing.

> 
> and to avoid breakage with audacious-plugins without updating
> audacious-plugins itself, can I, hypothetically, make libprojectm2 to be
> installable with libprojectm1?

Audacious-Plugins actual code will have to be ported to the new API. The
new API has incompatible changes. 

See the lines in my previous mail with ^'s below them, for a more
detailed explanation about the breakage trend in projectM.

>  
> > > about the change of SONAME by the upstream author, is it correct to
> > > change the SONAME if the library is compatible with the old one?
> > 
> > The library isn't compatible. Upstream breaks the API with every
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > release, so I gave up on them.
    ^^^^^^^

API breakage results in ABI breakage, which means the SONAME must be
changed, and *applications ported to the new API*.

At any rate, is there really any *point* in upgrading the library
anyway? The new versions do not introduce any new features that make the
effort worthwhile.

If you can't handle this, then please do not take the package, or at
least wait until after lenny is released to do so.

William

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: