[poky] wrong rpm name qt package

[Gerard van den Bosch]

On 05/26/2011 03:54 PM, Richard Purdie wrote:
> On Thu, 2011-05-26 at 13:22 +0200, Gerard van den Bosch wrote:
>> On 05/26/2011 11:43 AM, Richard Purdie wrote:
>>> On Thu, 2011-05-26 at 09:31 +0200, Gerard van den Bosch wrote:
>>>> I have developed a shared library using Qt, it compiles without any
>>>> problems but it goes wrong with rpm packaging.
>>>> When it packages it should create a rpm package with the name
>>>> "libxmlpcpqt" but it creates a package with "libxmlpcpqt1".
>>>> My question is where does the '1' come from?
>>>>
>>>> The install part from the recipe is as follows:
>>>> do_install() {
>>>>        install -d ${D}${libdir}
>>>>        install -m 0755 ${S}/${PN}.so ${D}${libdir}
>>>> }
>>>>
>>>> In
>>>> the /tmp/work/armv7a-poky-linux-gnueabi/libxmlpcpqt-0.1-r1/image/usr/lib the libxmlpcpqt.so file correctly exists.
>>> This happens as debian style package naming is enabled (debian.bbclass
>>> is inherited).
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>> I tried removing debian from the INHERITS+= variable in the poky.conf
>> but then it printed it couldn't find the function that is inside
>> debian.bbclass and didn't create the package.
>> Modifying debian.bbclass would be too drastic so I work around it like
>> this:
>> Added PACKAGES+= ${PN}1 to my recipe
>> Modified the IMAGE_INSTALL+= variable from libxmlpcpqt to libxmlpcpqt1
>> This resulted in a working solution.
> This is a bug and you should never need to do this. IMAGE_INSTALL should
> be getting remapped to the new names. The code that is meant to do that
> is at the top of image.bbclass:
>
>      # If we don't do this we try and run the mapping hooks while parsing which is slow
>      # bitbake should really provide something to let us know this...
>      if bb.data.getVar('BB_WORKERCONTEXT', d, True) is not None:
>          runtime_mapping_rename("PACKAGE_INSTALL", d)
>          runtime_mapping_rename("PACKAGE_INSTALL_ATTEMPTONLY", d)
>
> Can you check that the code is being called? I suspect something to do
> with the BB_WORKERCONTEXT variable has been broken. We should be doing
> this in a better way anyhow...
>
> Cheers,
>
> Richard
>
Ok, I am still using the Laverne release so maybe that's the problem, I will try to compile it on a system where I have the Bernard release tonight to ensure that the bug isn't fixed already.
If the problem still occurs there, I will check the suggested.
I will send an update as soon as possible.

Regards,
Gerard