On 09/21/2016 10:58 AM, Jaromír Mikeš wrote:
>> - libdrumkv1-dev: contains /usr/lib/${TRIPLET}/libdrumkv1.so.0 and
> Shouldn't be this /usr/lib/${TRIPLET}/libdrumkv1.so ?


>> /usr/include/
> There are no files in /usr/include/

in which case i think the entire -dev package is useless.

> I am not sure if API is public ... if I understand right shared lib
> should be used only by drumkv1 app and LV2 plugin

which makes it a private library, and should go into /usr/lib/drumkv1/
(or /usr/lib/${TRIPLET}/drumkv1/)

> - drumkv1: main binary package providing the application
> - libdrumkv1-0: contains the lib /usr/lib/${TRIPLET}/libdrumkv1.so.0*
> - libdrumkv1-dev: contains /usr/lib/${TRIPLET}/libdrumkv1.so
> - drumkv1-lv2: contains the LV2-plugins
> let me know please if I should rework it

so now that i begin to understand (sorry, but i'm sure you are more into
it than me), i would propose:

- drumkv1: main binary package providing the application and
- drumkv1-lv2: the LV2-plugins

drop the libdrumkv1 and libdrumkv1-dev packages altogether (this only
became clear to me after i fully understood the use of libdrumkv1.so).
i don't think there's a need to put the libdrumkv1.so* into a
${TRIPLET}-qualified path, since the drumkv1 binary package is NOT
"Multi-arch: same" anyhow (and LV2 is not multiarch either), so
/usr/lib/drumkv1/ should be good enough.
you might need to use rpath for that.

there is little use in shipping the librdumkv1.so symlink (of course the
libdrumkv1.so.0* must be shipped)

if others have different opinions, please speak up :-)


Attachment: signature.asc
Description: OpenPGP digital signature

pkg-multimedia-maintainers mailing list

Reply via email to