packaging a new LibLo release

[Stephen Sinclair]

Thanks for your quick response!

On Thu, Mar 14, 2013 at 2:37 PM, Felipe Sateler <fsateler at debian.org> wrote:
> 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?).

No, I haven't tried building them, I suppose I could try it.
Basically in this release I have made pthread an optional compile-time
dependency (on by default), but in either case the headers have no
reason to refer to pthread-specific things, so it seemed to make sense
to take it out.  (e.g. I am hoping to eventually have it use the Win32
API for threading on windows rather than depending on the pthreads
windows port.)


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

Okay.  I am not super concerned about having it included immediately
(although that would certainly be nice), I just want to make it
available for future releases.

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

That is not a bad idea, I'll maybe do that and see whether the
generated project file is compatible across different computers.

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

Great!

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

Ah, interesting.  I do however like the idea of someone other than me
verifying all the packaging details.  Anyway I can't offer immediately
as I have little time these days but I wouldn't mind learning more
about packaging in the long run.

Steve