packaging a new LibLo release

[Felipe Sateler]

On Thu, Mar 14, 2013 at 3:01 PM, Stephen Sinclair <radarsat1 at gmail.com> wrote:
> Hello,

Hi Stephen,

>
> It was suggested I write to this address for questions about packaging
> liblo.  I am the liblo maintainer, and I'm starting to prepare for a
> new upstream release 0.27 of this library. I just wanted to verify a
> few things before doing the release.
>
> My goal for this release is to ensure that there is no need to change
> soname versioning, and that packages depending on liblo do not need to
> be recompiled.
>
> I have used icheck to verify that the ABI and API are
> forward-compatible.  (But not backward-compatible.. some functions
> have been added.)
>
> However, one thing that has changed is that there used to be a line,
>
> #include <pthread.h>
>
> in one of the headers.  I have removed this line since it is not
> necessary, however icheck fails unless I add it back to one of the
> headers.
>
> From a packager's point of view, is it worth adding it back to satisfy icheck?

I would say it is not necessary. Including pthread.h was a bug, so it
is correct to fix it. Unfortunately, it may cause build failures (I
don't know if any actually materialize). On the other hand, the number
of reverse build-deps in debian is relatively small (30), and most of
them fall under the pkg-multimedia umbrella, so we can fix them (have
you tried building the reverse deps?).

But in any case all of this would be for after the wheezy release, as
it is too late in the release process. We could still upload the new
liblo to experimental and see if reverse deps build.

> Anything else I should consider in terms of packaging from an upstream
> point of view?  I'd like this to go as smoothly as possible, since
> I've made mistakes in the past.
>
> Jonas Smedegaard has already reminded me of the issue with the
> premake4.exe binary that I included in the last release for Windows
> users.  This was mainly inspired by ODE (ode.org) that includes it as
> a solution to generate Visual Studio project files.
>
> I'm happy for alternative suggestions on how to provide a source-only
> release while still allowing a smooth experience for Windows users.  I
> suppose I could ask them to download premake separately..

Or pregenerate the visual studio project file?

Aside from that binary, I don't see any issues with liblo packaging.
We don't carry any patches nor do anything weird, so I'd say the
package does not give us packagers any problems.


PS: it appears you use Debian. If you want to join us in maintaining
liblo at the pkg-multimedia team, you are more than welcome!

-- 

Saludos,
Felipe Sateler