Colin Guthrie wrote:
> Hmmmmmm.
>
> libpulse requires libpulsecommon but libpulsecommon accesses functions
> provided by libpulse.... ?
>
> e.g. pa_xfree is used in libpulsecommon, but it's actually part of
> libpulse. ditto for lots of string stuff.
>
> Is this deliberate? Is seriously breaks building for me (I can work
> around it but it's surely not nice to do this?)
>
> Col
>
Also I wonder why, now that libpulsecore is no longer a normal shared
library, but more of a "module" why is it stored as follows:
%{_libdir}/libpulsecommon-0.9.13.so
%{_libdir}/libpulsecore-0.9.13.so
Whereas modules are stored like:
%{_libdir}/pulse-0.9.13/modules/libalsa-util.so
Would it not make more sense to store it as:
%{_libdir}/pulse-0.9.13/libpulsecommon.so
%{_libdir}/pulse-0.9.13/libpulsecore.so
Also can the API version and PA version be bumped earlier in master
(e.g. immediately after tagging the older release)? This would allow for
a "package" that was shipping a pre-release version of 0.9.14 to keep
it's version consistent. This is not a biggie, but I think quite a few
projects work like that, and it may not fit with personal preference etc. :)
Cheers
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
