[OE-core] [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

Mark Hatle mark.hatle at windriver.com
Thu May 30 12:22:24 UTC 2013


On 5/30/13 5:46 AM, Phil Blundell wrote:
> On Wed, 2013-05-29 at 22:59 +0100, Richard Purdie wrote:
>> Fair enough. Can we at least match the pattern do_split_packages uses,
>> i.e.:
>>
>> PACKAGES_DYNAMIC = "^${PN}-lib.*"
>>
>> I'm a little paranoid about adding wildcards like ${PN}-* as the
>> potential for namespace problems is not insignificant, particularly if
>> you know the horrible things bitbake does with this behind the
>> scenes :/.
>
> Does it really need to be dynamic at all?  I don't think the list of
> libraries installed by ncurses varies all that much (apart from WIDEC
> on/off), and nor is it overwhelmingly large.  It doesn't seem like it
> would be all that hard to arrange for the right stuff to be added to
> PACKAGES at parse time, in which case this whole problem would just go
> away.

Certainly possible.  That's not the tactic we took on resolving the issue.  One 
line change vs significantly modifying the package.   The following is the chunk 
that handles the dynamic generation (from ncurses.inc)

python populate_packages_prepend () {
     libdir = d.expand("${libdir}")
     base_libdir = d.expand("${base_libdir}")
     pnbase = d.expand("${PN}-lib%s")
     do_split_packages(d, libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses %s 
library', prepend=True, extra_depends = '', allow_links=True)
     if libdir is not base_libdir:
         do_split_packages(d, base_libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses 
%s library', prepend=True, extra_depends = '', allow_links=True)
}

Beyond this even, the package has a number of dynamic configurations that should 
probably be done based on libc and/or distro flags as well.

So this is probably a job for a janitor task.

I still think as a minimal change the PACKAGES_DYNAMIC is the correct change, 
but as you said -- during a cleanup -- the need for PACKAGES_DYNAMIC can be 
diminished or removed.

--Mark

> p.
>
>




More information about the Openembedded-core mailing list