Patchwork package.bbclass: Let pn be eglibc for eglibc-locale

login
mail settings
Submitter Saul Wold
Date July 26, 2012, 6:49 p.m.
Message ID <1343328564-3644-1-git-send-email-sgw@linux.intel.com>
Download mbox | patch
Permalink /patch/33157/
State New
Headers show

Comments

Saul Wold - July 26, 2012, 6:49 p.m.
From: Khem Raj <raj.khem@gmail.com>

eglibc-locale is creating the individual locale files which have
runtime dependency on ${PN} which is 'eglibc-locale' but problem
is that eglibc-locale is an empty package and does not get created
so when one asks for adding locales to image then due to the missing
dependency in the feeds root file system can not be created.

This patch treates eglibc-locale as if it was eglibc and hence
the dependency then is created on libc6 and not not existing
eglibc-locale package.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
 meta/classes/package.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
Phil Blundell - July 26, 2012, 6:58 p.m.
On Thu, 2012-07-26 at 11:49 -0700, Saul Wold wrote:
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 0c7fe80..06e2e04 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -389,6 +389,8 @@ python package_do_split_locales() {
>  
>      dvar = d.getVar('PKGD', True)
>      pn = d.getVar('PN', True)
> +    if pn == "eglibc-locale":
> +        pn = "eglibc"

Bletch!  There must surely be some way to solve this problem without
hacking recipe names into package.bbclass.

p.
Khem Raj - July 26, 2012, 8:16 p.m.
On Thu, Jul 26, 2012 at 11:58 AM, Phil Blundell <philb@gnu.org> wrote:
>
> Bletch!  There must surely be some way to solve this problem without
> hacking recipe names into package.bbclass.

Yes making eglibc-locale base package to be non empty. So if we put in
something there that it never turns out to be empty is one way
Richard Purdie - July 26, 2012, 8:38 p.m.
On Thu, 2012-07-26 at 13:16 -0700, Khem Raj wrote:
> On Thu, Jul 26, 2012 at 11:58 AM, Phil Blundell <philb@gnu.org> wrote:
> >
> > Bletch!  There must surely be some way to solve this problem without
> > hacking recipe names into package.bbclass.
> 
> Yes making eglibc-locale base package to be non empty. So if we put in
> something there that it never turns out to be empty is one way

Well, having things depending on eglibc-locale-locale is wrong in many
ways :/. eglibc is just the only package we split the locale generation
into a separate recipe for.

A more generic check in there which would work for multiple libcs would
be:

if pn.endswith("-locale"):
    pn = pn[:-7]

the other alternative which comes to mind would be so set a variable
with the name we want used there, defaulting it to PN.

Cheers,

Richard
Mark Hatle - July 26, 2012, 8:52 p.m.
On 7/26/12 3:38 PM, Richard Purdie wrote:
> On Thu, 2012-07-26 at 13:16 -0700, Khem Raj wrote:
>> On Thu, Jul 26, 2012 at 11:58 AM, Phil Blundell <philb@gnu.org> wrote:
>>>
>>> Bletch!  There must surely be some way to solve this problem without
>>> hacking recipe names into package.bbclass.
>>
>> Yes making eglibc-locale base package to be non empty. So if we put in
>> something there that it never turns out to be empty is one way
>
> Well, having things depending on eglibc-locale-locale is wrong in many
> ways :/. eglibc is just the only package we split the locale generation
> into a separate recipe for.
>
> A more generic check in there which would work for multiple libcs would
> be:
>
> if pn.endswith("-locale"):
>      pn = pn[:-7]

This sounds like a good alternative.  It still enables breakups of the locales, 
if appropriate, with the only rule being that the core part of the name be 
consistent with whatever it's targeting.

i.e. eglibc and eglibc-locale

> the other alternative which comes to mind would be so set a variable
> with the name we want used there, defaulting it to PN.

I had suggested changing the PN of the eglibc-locale to "eglibc", but I believe 
Khem ran into a number of problems doing this.

--Mark

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Phil Blundell - July 26, 2012, 8:53 p.m.
On Thu, 2012-07-26 at 21:38 +0100, Richard Purdie wrote:
> the other alternative which comes to mind would be so set a variable
> with the name we want used there, defaulting it to PN.

That sounds like the most wholesome plan to me.

p.
Khem Raj - July 26, 2012, 9:27 p.m.
On Thu, Jul 26, 2012 at 1:53 PM, Phil Blundell <philb@gnu.org> wrote:
> On Thu, 2012-07-26 at 21:38 +0100, Richard Purdie wrote:
>> the other alternative which comes to mind would be so set a variable
>> with the name we want used there, defaulting it to PN.
>
> That sounds like the most wholesome plan to me.

can we use BPN, unless we generate locale for native and nativesdk
cross and crosssdk
class of recipes that should work too. I thought about it  and thought
it was too
intrusive.
Mark Hatle - July 26, 2012, 9:47 p.m.
On 7/26/12 4:27 PM, Khem Raj wrote:
> On Thu, Jul 26, 2012 at 1:53 PM, Phil Blundell <philb@gnu.org> wrote:
>> On Thu, 2012-07-26 at 21:38 +0100, Richard Purdie wrote:
>>> the other alternative which comes to mind would be so set a variable
>>> with the name we want used there, defaulting it to PN.
>>
>> That sounds like the most wholesome plan to me.
>
> can we use BPN, unless we generate locale for native and nativesdk
> cross and crosssdk
> class of recipes that should work too. I thought about it  and thought
> it was too
> intrusive.

There are cases for multilibs where locales for specific multilib packages will 
be generated.  We theoretically could generate them for native(sdk) and 
cross(sdk) as well, but I don't believe we do that in the general cases.

--Mark
Khem Raj - July 29, 2012, 8:22 p.m.
On Thu, Jul 26, 2012 at 2:47 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 7/26/12 4:27 PM, Khem Raj wrote:
>>
>> On Thu, Jul 26, 2012 at 1:53 PM, Phil Blundell <philb@gnu.org> wrote:
>>>
>>> On Thu, 2012-07-26 at 21:38 +0100, Richard Purdie wrote:
>>>>
>>>> the other alternative which comes to mind would be so set a variable
>>>> with the name we want used there, defaulting it to PN.
>>>
>>>
>>> That sounds like the most wholesome plan to me.
>>
>>
>> can we use BPN, unless we generate locale for native and nativesdk
>> cross and crosssdk
>> class of recipes that should work too. I thought about it  and thought
>> it was too
>> intrusive.
>
>
> There are cases for multilibs where locales for specific multilib packages
> will be generated.  We theoretically could generate them for native(sdk) and
> cross(sdk) as well, but I don't believe we do that in the general cases.
>
> --Mark


After RPs fix and Paul's root file system rework I am still seeing

temp/run.do_rootfs.25593: 932: local: locale-base-en-gb: bad variable name



>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - July 29, 2012, 8:34 p.m.
>
>
> After RPs fix and Paul's root file system rework I am still seeing
>
> temp/run.do_rootfs.25593: 932: local: locale-base-en-gb: bad variable name
>

OK I think my fault is that I am dash'ing and not bash'ing and
meta/classes/package_rpm.bbclass is full of bashism

Patch

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 0c7fe80..06e2e04 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -389,6 +389,8 @@  python package_do_split_locales() {
 
     dvar = d.getVar('PKGD', True)
     pn = d.getVar('PN', True)
+    if pn == "eglibc-locale":
+        pn = "eglibc"
 
     if pn + '-locale' in packages:
         packages.remove(pn + '-locale')