Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   RFC: libprojectM, new upstream version. (http://www.linux-archive.org/debian-development/126164-rfc-libprojectm-new-upstream-version.html)

William Pitcock 07-16-2008 10:46 PM

RFC: libprojectM, new upstream version.
 
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.

> 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.

William

Francesco Namuri 07-16-2008 11:13 PM

RFC: libprojectM, new upstream version.
 
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?

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

> > 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.

Best Regards,
francesco

William Pitcock 07-17-2008 12:37 AM

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

Francesco Namuri 07-17-2008 01:00 PM

RFC: libprojectM, new upstream version.
 
Il giorno mer, 16/07/2008 alle 19.37 -0500, William Pitcock ha scritto:
> 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.

Yes, I've read it and I've read "Debian Library Packaging guide" too,
I've asked here in mentors-list to have a confirm of my understanding of
the documentation. Unfortunately this clarification is arrived too late
and I've send to ftp-master a very bad package. My mistake, I've hurried
without any reason...

> > 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.

please, this is not necessary, I've understood your previous email
without any need of highlights, IMHO the point of my previous question
was another...

> > > > 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*.

again I've understood; you are speaking about this project in
particular, my question has been (in my intention) more general...

> 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.

I'm thinking about this.

> 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.

I can handle this, maybe I need to ask for some help, but I can handle
this. Otherwise I would not have taken this package.

Best Regards,
francesco

Francesco Namuri 07-17-2008 05:18 PM

RFC: libprojectM, new upstream version.
 
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.

audacious-plugins is already compatible with the new version of
libprojectM... I've looked at the logs of buildd of audacious-plugins
and the projectM plugin isn't build from version 1.4.5-1, so the update
of libprojectM don't break anything, indeed I tried to compile with
libprojectM 1.2 and it builds also the projectM plugin... So I'm going
to package the new library version...

> > 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.

Best regards,
francesco

William Pitcock 07-17-2008 10:30 PM

RFC: libprojectM, new upstream version.
 
On Thu, 2008-07-17 at 19:18 +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.
>
> audacious-plugins is already compatible with the new version of
> libprojectM... I've looked at the logs of buildd of audacious-plugins
> and the projectM plugin isn't build from version 1.4.5-1, so the update
> of libprojectM don't break anything, indeed I tried to compile with
> libprojectM 1.2 and it builds also the projectM plugin... So I'm going
> to package the new library version...

Then you cause a feature regression. *great*.

>
> > > 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.
>
> Best regards,
> francesco

Francesco Namuri 07-18-2008 03:01 PM

RFC: libprojectM, new upstream version.
 
Il giorno gio, 17/07/2008 alle 17.30 -0500, William Pitcock ha scritto:
> > audacious-plugins is already compatible with the new version of
> > libprojectM... I've looked at the logs of buildd of
> audacious-plugins
> > and the projectM plugin isn't build from version 1.4.5-1, so the
> update
> > of libprojectM don't break anything, indeed I tried to compile with
> > libprojectM 1.2 and it builds also the projectM plugin... So I'm
> going
> > to package the new library version...
>
> Then you cause a feature regression. *great*.

no I don't cause any feature regression, because audacious-plugins
doesn't build any projectM plugin. please check your buildd logs.

contrary with the version 1.2.0 the plugin builds, so it's a feature
enhancement, not a regression...


All times are GMT. The time now is 12:57 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.