Thanks for your quick response! On Thu, Mar 14, 2013 at 2:37 PM, Felipe Sateler <[email protected]> wrote: > On Thu, Mar 14, 2013 at 3:01 PM, Stephen Sinclair <[email protected]> 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 _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
