Patchwork [18/21] Fix problems expanding the IMAGE_INSTALL package groups

login
register
mail settings
Submitter Mark Hatle
Date May 29, 2013, 3:10 p.m.
Message ID <1369840203-21898-19-git-send-email-mark.hatle@windriver.com>
Download mbox | patch
Permalink /patch/50739/
State New
Headers show

Comments

Mark Hatle - May 29, 2013, 3:10 p.m.
From: Jason Wessel <jason.wessel@windriver.com>

The ncurses package was generating the following error as a result
of not specifing the PACKAGES_DYNAMIC correctly.  This error only
appear when using the IMAGE_INSTALL list that has been expanded by
the hob or from the pkgdata.

ERROR: Nothing RPROVIDES 'ncurses-libtinfo'

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-core/ncurses/ncurses.inc | 2 ++
 1 file changed, 2 insertions(+)
Richard Purdie - May 29, 2013, 9:10 p.m.
On Wed, 2013-05-29 at 10:10 -0500, Mark Hatle wrote:
> From: Jason Wessel <jason.wessel@windriver.com>
> 
> The ncurses package was generating the following error as a result
> of not specifing the PACKAGES_DYNAMIC correctly.  This error only
> appear when using the IMAGE_INSTALL list that has been expanded by
> the hob or from the pkgdata.
> 
> ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
> 
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> ---
>  meta/recipes-core/ncurses/ncurses.inc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
> index 8a81381..584ad46 100644
> --- a/meta/recipes-core/ncurses/ncurses.inc
> +++ b/meta/recipes-core/ncurses/ncurses.inc
> @@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE"
>  # natives don't generally look in base_libdir
>  base_libdir_class-native = "${libdir}"
>  
> +PACKAGES_DYNAMIC = "^${PN}-.*"
> +
>  # Fall back to the host termcap / terminfo for -nativesdk and -native
>  # The reality is a work around for strange problems with things like
>  # "bitbake -c menuconfig busybox" where it cannot find the terminfo

I'm pretty sure I talked to Jason about this and we concluded this was
fixed with some other change in master. Certainly this fix as it stands
doesn't sound right.

Cheers,

Richard
Mark Hatle - May 29, 2013, 9:28 p.m.
On 5/29/13 4:10 PM, Richard Purdie wrote:
> On Wed, 2013-05-29 at 10:10 -0500, Mark Hatle wrote:
>> From: Jason Wessel <jason.wessel@windriver.com>
>>
>> The ncurses package was generating the following error as a result
>> of not specifing the PACKAGES_DYNAMIC correctly.  This error only
>> appear when using the IMAGE_INSTALL list that has been expanded by
>> the hob or from the pkgdata.
>>
>> ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
>>
>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>> ---
>>   meta/recipes-core/ncurses/ncurses.inc | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
>> index 8a81381..584ad46 100644
>> --- a/meta/recipes-core/ncurses/ncurses.inc
>> +++ b/meta/recipes-core/ncurses/ncurses.inc
>> @@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE"
>>   # natives don't generally look in base_libdir
>>   base_libdir_class-native = "${libdir}"
>>
>> +PACKAGES_DYNAMIC = "^${PN}-.*"
>> +
>>   # Fall back to the host termcap / terminfo for -nativesdk and -native
>>   # The reality is a work around for strange problems with things like
>>   # "bitbake -c menuconfig busybox" where it cannot find the terminfo
>
> I'm pretty sure I talked to Jason about this and we concluded this was
> fixed with some other change in master. Certainly this fix as it stands
> doesn't sound right.

The original thread included libpcre, it was libpcre side was in fact fixed 
prior to the initial patch being submitted.  ncurses however is still broken.

If I revert this commit in my tree, and add to IMAGE_INSTALL "ncurses-libtinfo", 
I get the following failure:

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'ncurses-libtinfo' (but 
/msp-lpggp21/lmhatle/build-1/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb 
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'ncurses-libtinfo' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['ncurses-libtinfo']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 
'ncurses-libtinfo']

with the patch applied it completes successfully.

Reproducer:

Add to conf/local.conf

IMAGE_INSTALL_append = " ncurses-libtinfo"

bitbake core-image-minimal

> Cheers,
>
> Richard
>
Richard Purdie - May 29, 2013, 9:59 p.m.
On Wed, 2013-05-29 at 16:28 -0500, Mark Hatle wrote:
> On 5/29/13 4:10 PM, Richard Purdie wrote:
> > On Wed, 2013-05-29 at 10:10 -0500, Mark Hatle wrote:
> >> From: Jason Wessel <jason.wessel@windriver.com>
> >>
> >> The ncurses package was generating the following error as a result
> >> of not specifing the PACKAGES_DYNAMIC correctly.  This error only
> >> appear when using the IMAGE_INSTALL list that has been expanded by
> >> the hob or from the pkgdata.
> >>
> >> ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
> >>
> >> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> >> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> >> ---
> >>   meta/recipes-core/ncurses/ncurses.inc | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
> >> index 8a81381..584ad46 100644
> >> --- a/meta/recipes-core/ncurses/ncurses.inc
> >> +++ b/meta/recipes-core/ncurses/ncurses.inc
> >> @@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE"
> >>   # natives don't generally look in base_libdir
> >>   base_libdir_class-native = "${libdir}"
> >>
> >> +PACKAGES_DYNAMIC = "^${PN}-.*"
> >> +
> >>   # Fall back to the host termcap / terminfo for -nativesdk and -native
> >>   # The reality is a work around for strange problems with things like
> >>   # "bitbake -c menuconfig busybox" where it cannot find the terminfo
> >
> > I'm pretty sure I talked to Jason about this and we concluded this was
> > fixed with some other change in master. Certainly this fix as it stands
> > doesn't sound right.
> 
> The original thread included libpcre, it was libpcre side was in fact fixed 
> prior to the initial patch being submitted.  ncurses however is still broken.
> 
> If I revert this commit in my tree, and add to IMAGE_INSTALL "ncurses-libtinfo", 
> I get the following failure:
> 
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'ncurses-libtinfo' (but 
> /msp-lpggp21/lmhatle/build-1/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb 
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'ncurses-libtinfo' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['ncurses-libtinfo']
> ERROR: Required build target 'core-image-minimal' has no buildable providers.
> Missing or unbuildable dependency chain was: ['core-image-minimal', 
> 'ncurses-libtinfo']
> 
> with the patch applied it completes successfully.
> 
> Reproducer:
> 
> Add to conf/local.conf
> 
> IMAGE_INSTALL_append = " ncurses-libtinfo"
> 
> bitbake core-image-minimal


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 :/.

Cheers,

Richard
Phil Blundell - May 30, 2013, 10:46 a.m.
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.

p.
Mark Hatle - May 30, 2013, 12:22 p.m.
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.
>
>
Richard Purdie - May 30, 2013, 8:10 p.m.
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

Patch

diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
index 8a81381..584ad46 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -29,6 +29,8 @@  BUILD_CPPFLAGS += "-D_GNU_SOURCE"
 # natives don't generally look in base_libdir
 base_libdir_class-native = "${libdir}"
 
+PACKAGES_DYNAMIC = "^${PN}-.*"
+
 # Fall back to the host termcap / terminfo for -nativesdk and -native
 # The reality is a work around for strange problems with things like
 # "bitbake -c menuconfig busybox" where it cannot find the terminfo