Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups
Date: Thu, 30 May 2013 21:10:02 +0100	[thread overview]
Message-ID: <1369944602.14887.332.camel@ted> (raw)
In-Reply-To: <51A74480.6080102@windriver.com>

On Thu, 2013-05-30 at 07:22 -0500, Mark Hatle wrote:
> 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.

I've mixed feelings on this. For now I've taken the PACKAGES_DYNAMIC
change since its simple and I'm happier now the "lib" is in there and it
matches the package split. Any other patches will be considered on their
own merit, as usual...

Cheers,

Richard