[poky] wrong rpm name qt package

[Richard Purdie]

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