[yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

[Dinh Nguyen (dinhn)]

>>> I wonder why do we want to override default PACKAGES here. If we can leave that alone things would work out on its own.

I did remove the PACKAGES setting in my .bb — so all default packages were built. But still having some other issue as stated in other emails.

Thanks Khem.
  —Dinh



On 10/5/16, 8:34 AM, "Khem Raj" <raj.khem at gmail.com> wrote:

>I wonder why do we want to override default PACKAGES here. If we can leave
>that alone things would work out on its own.
>
>On Tue, Oct 4, 2016 at 11:55 PM, Paul Eggleton
><paul.eggleton at linux.intel.com> wrote:
>> On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote:
>>> Thanks much Paul.
>>>
>>> >>>> PACKAGES = "${PN}" should work
>>>
>>> It solved the early error “ c-mlib listed in PACKAGES multiple times, this
>>> leads to packaging errors” — Thanks again.
>>>
>>>
>>> But running into other issue. Below is my do_install
>>>
>>> do_install () {
>>>       oe_runmake all
>>>       install -d ${D}${libdir}
>>>       install -d ${D}${bindir}
>>>       install -m 0644 ${S}/target/libmlib.so ${D}${libdir}
>>>       install -m 0644 ${S}/target/datamodel_cache ${D}${bindir}
>>>       install -m 0644 ${S}/target/invoke ${D}${bindir}
>>>       install -m 0644 ${S}/target/invoke_b ${D}${bindir}
>>>       install -m 0644 ${S}/target/protocol_infra ${D}${bindir}
>>>       install -m 0644 ${S}/target/publisher ${D}${bindir}
>>>       install -m 0644 ${S}/target/rpc-register ${D}${bindir}
>>>       install -m 0644 ${S}/target/service ${D}${bindir}
>>>       install -m 0644 ${S}/target/subscriber ${D}${bindir}
>>> }
>>>
>>> PACKAGES = "${PN}"
>>> FILES_${PN} = "/usr/bin/datamodel_cache \
>>>               /usr/bin/invoke \
>>>               /usr/bin/invoke_b \
>>>               /usr/lib/libmlib.so \
>>>               /usr/bin/protocol_infra \
>>>               /usr/bin/publisher \
>>>               /usr/bin/rpc-register \
>>>               /usr/bin/service \
>>>               /usr/bin/subscriber"
>>>
>>>
>>>
>>> And under ${S}/target, it has the libmlib.so and other binaries built,
>>> And I intended to copy the .so to ${D}${libdir} and binarires to
>>> ${D}${bindir}. I am able to build the c-mlib package as shown below:
>>
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find
>>> tmp/deploy | grep c-mlib
>>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>>>
>>>
>>> The problem is that, after "bitbake c-mlib”, it moved all sources under ${S}
>>> to /usr/src/debug etc..
>>> I googled but unable to find the root cause.
>>> Would you and other can help to identify the issue?
>>> NOTE: Executing RunQueue Tasks
>>> ERROR: QA Issue: c-mlib: Files/directories were installed but not shipped
>>>   /usr/src
>>>   /usr/lib/.debug
>>>   /usr/lib/.debug/libmlib.so
>>>   /usr/src/debug
>>>   /usr/src/debug/c-mlib
>>>   /usr/src/debug/c-mlib/1.1-r0
>>>   /usr/src/debug/c-mlib/1.1-r0/git
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src
>>>   /usr/src/debug/c-mlib/1.1-r0/git/include
>>>   /usr/src/debug/c-mlib/1.1-r0/git/deps
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_metrics.c
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_util.c
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_local_metrics.c
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/utils
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/service_sdk
>>>   /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_service_cache.c
>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_wrapper.c
>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_dsa.c
>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/include
>>> ….
>>
>> This is what I suspected would happen - these files would normally be part of
>> the ${PN}-dbg package, but since you've removed that from PACKAGES, they are
>> ending up unpackaged and that is not allowed.
>>
>> Like the other responder I would suggest you not set PACKAGES - instead you
>> just need to take steps so that the .so file doesn't end up in the ${PN}-dev
>> package. You could do something like this:
>>
>> FILES_${PN}-dev = "${includedir}"
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto