Rene Engelhard wrote:
Hi, Mikael Magnusson wrote:I choose to name them libportaudio0[-dev] and libportaudio19-0[-dev] with libportaudio0 and libportaudio19-0 as SONAMEs respectively, and I think my naming scheme has an advantages. If portaudio v19 when release is backward compatible with v18, then libportaudio19-0[-dev] can be renamed to libportaudio0[-dev].I just did a diff between portaudio v18.1 and the CVS anspshot I packaged. They renamed functions (removing the old ones): e.g. PaQueryDevice -> PaOSS_QueryDevice. And AFAIS function signatures, too. So v18 and v19 *are* ABI-incompatible (which also alreyd was implied of the API changes, see above).
PaQueryDevice and PaOSS_QueryDevice seem to be internal functions and aren't declared in portaudio.h.
So you *need* to do a split completely and this means also wrt SONAMEs, v19 will not be compatible with pplications written for/linked against v18.
Yes, I know they are ABI-incompatible and I use the SONAMEs libportaudio.so.0 and libportaudio-19.so.0 respectively in my packages.
According to the first paragraph in Debian Policy Manual section 10.2 "Libraries", you must compile all source twice. Isn't this required anymore, as I can't see this happen in your package?Well... I never saw bad implications of static libraries built with -fPIC, contrary I saw that this is good since some applications/other dynamic libraries wanting to link against portaudio will not fail. Some arch require -fPIC for linking into a (dynamic) app and dynamic librar
Yes, dynamic libraries must be compiled with -fPIC and static libraries must not be.
According to section 1.1: "Packages that do not conform to the guidelines denoted by must (or required) will generally not be considered acceptable for the Debian distribution."
Regards, Mikael