[PATCH 0/3][RFC] rpm: multilib related fixes

[PATCH 0/3][RFC] rpm: multilib related fixes

[Dongxiao Xu]

Hi Richard and Mark,

This pull request is to fix several multilib related issues to rpm, includes:

1) Add architecture information in RPM spec file to fix bug 1457.
2) For recipes with MACHINE_ARCH as PACKAGE_ARCH, the deploy folder is defined as tmp/deploy/lib32(64)-${MACHINE_ARCH} to avoid confliction with normal recipe deploy folder.
3) Add MULTILIB_IMAGE_INSTALL in the package installation list.

Please help to review them.

Thanks,
Dongxiao

Dongxiao Xu (3):
  package_rpm: add architecture info in rpm spec file
  rpm: add multilib prefix for archs under deploy/rpm
  multilib: install MULTILIB_PACKAGE_INSTALL

 meta/classes/multilib.bbclass    |    6 +++
 meta/classes/package_rpm.bbclass |   78 +++++++++++++++++++++++++++++++-------
 meta/classes/rootfs_rpm.bbclass  |    8 +++-
 3 files changed, 77 insertions(+), 15 deletions(-)

[PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Dongxiao Xu]

For supporting multilib, architecture information is needed in package
require/provide/suggest/recommend fields.

Use DEFAULTTUNE value as the postfix.

For "all" arch recipe, it requires "all" arch recipe with no postfix,
but provides all possible multilib archs.

For example, qemu-config:

Requires: rsync
Requires: update-rc.d
Requires: task-core-nfs-server
Requires: distcc
Requires: oprofileui-server
Requires: dbus-x11
Requires: bash
Provides: qemu-config.x86
Provides: qemu-config.x86-64

For other recipe like zlib:

Requires: libc6.x86-64 >= 2.13
Provides: zlib.x86-64

[YOCTO #1457]

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 meta/classes/multilib.bbclass    |    1 +
 meta/classes/package_rpm.bbclass |   36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 583d76b..76c86b2 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -23,6 +23,7 @@ python multilib_virtclass_handler () {
     e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
     e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
     e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant, e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
+    e.data.setVar("SAVED_DEFAULTTUNE", e.data.getVar("DEFAULTTUNE", True))
     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
 }
 
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 9ef1acd..ea0a079 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -350,6 +350,7 @@ package_install_internal_rpm () {
 python write_specfile () {
 	import textwrap
 	import oe.packagedata
+	import re
 
 	# We need a simple way to remove the MLPREFIX from the package name,
 	# and dependency information...
@@ -498,6 +499,8 @@ python write_specfile () {
 
 		splitname    = strip_multilib(pkgname, d)
 
+		defaulttune = bb.data.getVar('DEFAULTTUNE', localdata, True)
+
 		splitsummary = (bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or ".")
 		splitversion = (bb.data.getVar('PKGV', localdata, True) or "").replace('-', '+')
 		splitrelease = (bb.data.getVar('PKGR', localdata, True) or "")
@@ -528,6 +531,39 @@ python write_specfile () {
 		if pkg == d.getVar("PN", True):
 			splitrprovides = splitrprovides + " " + (d.getVar('ALTERNATIVE_LINK', True) or '') + " " + (d.getVar('ALTERNATIVE_LINKS', True) or '')
 
+		package_arch = bb.data.getVar('PACKAGE_ARCH', localdata, True)
+
+		splitrprovides = splitrprovides + " " + splitname + "." + defaulttune
+		if package_arch != "all":
+			pattern = '\([^()]*\)'
+			prog = re.compile(pattern)
+
+			str_list = [splitrdepends, splitrrecommends, splitrsuggests]
+			for e in range(len(str_list)):
+				brackets = prog.findall(str_list[e])
+				for i in range(len(brackets)):
+					str_list[e] = str_list[e].replace(brackets[i], "#BRACKETS"+str(i)+"#")
+				tmp = ""
+				for i in str_list[e].split():
+					if i.startswith("#BRACKETS"):
+						tmp += " " + str(i)
+						continue
+					tmp += " " + str(i) + "." + defaulttune
+				str_list[e] = tmp
+				for i in range(len(brackets)):
+					str_list[e] = str_list[e].replace("#BRACKETS"+str(i)+"#", brackets[i])
+
+			[splitrdepends, splitrrecommends, splitrsuggests] = str_list
+		else:
+			variants = (bb.data.getVar("MULTILIB_VARIANTS", localdata, True) or "").split()
+			for variant in variants:
+				tune = bb.data.getVar("DEFAULTTUNE_virtclass-multilib-" + variant, localdata, True) or ""
+				if tune:
+					splitrprovides = splitrprovides + " " + splitname + "." + tune
+			tune = bb.data.getVar("SAVED_DEFAULTTUNE", localdata, True) or ""
+			if tune:
+				splitrprovides = splitrprovides + " " + splitname + "." + tune
+
 		# Gather special src/first package data
 		if srcname == splitname:
 			srcrdepends    = splitrdepends
-- 
1.7.1

Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Mark Hatle]

This patch is incorrect.  Architectural information should not be in the
dependencies within RPM packages.

RPM is expected to find the proper version of a package to install based on the
existing dependency information.  I'm in the process of investigating why
certain items are not found properly.

--Mark

On 9/12/11 3:33 AM, Dongxiao Xu wrote:
> For supporting multilib, architecture information is needed in package
> require/provide/suggest/recommend fields.
> 
> Use DEFAULTTUNE value as the postfix.
> 
> For "all" arch recipe, it requires "all" arch recipe with no postfix,
> but provides all possible multilib archs.
> 
> For example, qemu-config:
> 
> Requires: rsync
> Requires: update-rc.d
> Requires: task-core-nfs-server
> Requires: distcc
> Requires: oprofileui-server
> Requires: dbus-x11
> Requires: bash
> Provides: qemu-config.x86
> Provides: qemu-config.x86-64
> 
> For other recipe like zlib:
> 
> Requires: libc6.x86-64 >= 2.13
> Provides: zlib.x86-64
> 
> [YOCTO #1457]
> 
> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> ---
>  meta/classes/multilib.bbclass    |    1 +
>  meta/classes/package_rpm.bbclass |   36 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index 583d76b..76c86b2 100644
> --- a/meta/classes/multilib.bbclass
> +++ b/meta/classes/multilib.bbclass
> @@ -23,6 +23,7 @@ python multilib_virtclass_handler () {
>      e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
>      e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
>      e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant, e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
> +    e.data.setVar("SAVED_DEFAULTTUNE", e.data.getVar("DEFAULTTUNE", True))
>      e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
>  }
>  
> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
> index 9ef1acd..ea0a079 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -350,6 +350,7 @@ package_install_internal_rpm () {
>  python write_specfile () {
>  	import textwrap
>  	import oe.packagedata
> +	import re
>  
>  	# We need a simple way to remove the MLPREFIX from the package name,
>  	# and dependency information...
> @@ -498,6 +499,8 @@ python write_specfile () {
>  
>  		splitname    = strip_multilib(pkgname, d)
>  
> +		defaulttune = bb.data.getVar('DEFAULTTUNE', localdata, True)
> +
>  		splitsummary = (bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or ".")
>  		splitversion = (bb.data.getVar('PKGV', localdata, True) or "").replace('-', '+')
>  		splitrelease = (bb.data.getVar('PKGR', localdata, True) or "")
> @@ -528,6 +531,39 @@ python write_specfile () {
>  		if pkg == d.getVar("PN", True):
>  			splitrprovides = splitrprovides + " " + (d.getVar('ALTERNATIVE_LINK', True) or '') + " " + (d.getVar('ALTERNATIVE_LINKS', True) or '')
>  
> +		package_arch = bb.data.getVar('PACKAGE_ARCH', localdata, True)
> +
> +		splitrprovides = splitrprovides + " " + splitname + "." + defaulttune
> +		if package_arch != "all":
> +			pattern = '\([^()]*\)'
> +			prog = re.compile(pattern)
> +
> +			str_list = [splitrdepends, splitrrecommends, splitrsuggests]
> +			for e in range(len(str_list)):
> +				brackets = prog.findall(str_list[e])
> +				for i in range(len(brackets)):
> +					str_list[e] = str_list[e].replace(brackets[i], "#BRACKETS"+str(i)+"#")
> +				tmp = ""
> +				for i in str_list[e].split():
> +					if i.startswith("#BRACKETS"):
> +						tmp += " " + str(i)
> +						continue
> +					tmp += " " + str(i) + "." + defaulttune
> +				str_list[e] = tmp
> +				for i in range(len(brackets)):
> +					str_list[e] = str_list[e].replace("#BRACKETS"+str(i)+"#", brackets[i])
> +
> +			[splitrdepends, splitrrecommends, splitrsuggests] = str_list
> +		else:
> +			variants = (bb.data.getVar("MULTILIB_VARIANTS", localdata, True) or "").split()
> +			for variant in variants:
> +				tune = bb.data.getVar("DEFAULTTUNE_virtclass-multilib-" + variant, localdata, True) or ""
> +				if tune:
> +					splitrprovides = splitrprovides + " " + splitname + "." + tune
> +			tune = bb.data.getVar("SAVED_DEFAULTTUNE", localdata, True) or ""
> +			if tune:
> +				splitrprovides = splitrprovides + " " + splitname + "." + tune
> +
>  		# Gather special src/first package data
>  		if srcname == splitname:
>  			srcrdepends    = splitrdepends

Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Xu, Dongxiao]

Hi Mark,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Monday, September 12, 2011 10:52 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info in rpm
> spec file
> 
> This patch is incorrect.  Architectural information should not be in the
> dependencies within RPM packages.
> 
> RPM is expected to find the proper version of a package to install based on the
> existing dependency information.  I'm in the process of investigating why
> certain items are not found properly.

Take "task-core-boot-1.0-r8.qemux86_64.rpm" as an example, and it has dependency on tinylogin, how can it determine whether it is depends on " tinylogin-1.4-r7.x86_64.rpm" or "tinylogin-1.4-r7.x86.rpm".

Thanks,
Dongxiao

> 
> --Mark
> 
> On 9/12/11 3:33 AM, Dongxiao Xu wrote:
> > For supporting multilib, architecture information is needed in package
> > require/provide/suggest/recommend fields.
> >
> > Use DEFAULTTUNE value as the postfix.
> >
> > For "all" arch recipe, it requires "all" arch recipe with no postfix,
> > but provides all possible multilib archs.
> >
> > For example, qemu-config:
> >
> > Requires: rsync
> > Requires: update-rc.d
> > Requires: task-core-nfs-server
> > Requires: distcc
> > Requires: oprofileui-server
> > Requires: dbus-x11
> > Requires: bash
> > Provides: qemu-config.x86
> > Provides: qemu-config.x86-64
> >
> > For other recipe like zlib:
> >
> > Requires: libc6.x86-64 >= 2.13
> > Provides: zlib.x86-64
> >
> > [YOCTO #1457]
> >
> > Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> > ---
> >  meta/classes/multilib.bbclass    |    1 +
> >  meta/classes/package_rpm.bbclass |   36
> ++++++++++++++++++++++++++++++++++++
> >  2 files changed, 37 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/classes/multilib.bbclass
> > b/meta/classes/multilib.bbclass index 583d76b..76c86b2 100644
> > --- a/meta/classes/multilib.bbclass
> > +++ b/meta/classes/multilib.bbclass
> > @@ -23,6 +23,7 @@ python multilib_virtclass_handler () {
> >      e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> >      e.data.setVar("SHLIBSDIR_virtclass-multilib-" +
> variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
> >      e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant,
> > e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
> > +    e.data.setVar("SAVED_DEFAULTTUNE",
> e.data.getVar("DEFAULTTUNE",
> > + True))
> >      e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) +
> > override)  }
> >
> > diff --git a/meta/classes/package_rpm.bbclass
> > b/meta/classes/package_rpm.bbclass
> > index 9ef1acd..ea0a079 100644
> > --- a/meta/classes/package_rpm.bbclass
> > +++ b/meta/classes/package_rpm.bbclass
> > @@ -350,6 +350,7 @@ package_install_internal_rpm () {  python
> > write_specfile () {
> >  	import textwrap
> >  	import oe.packagedata
> > +	import re
> >
> >  	# We need a simple way to remove the MLPREFIX from the package name,
> >  	# and dependency information...
> > @@ -498,6 +499,8 @@ python write_specfile () {
> >
> >  		splitname    = strip_multilib(pkgname, d)
> >
> > +		defaulttune = bb.data.getVar('DEFAULTTUNE', localdata, True)
> > +
> >  		splitsummary = (bb.data.getVar('SUMMARY', localdata, True) or
> bb.data.getVar('DESCRIPTION', localdata, True) or ".")
> >  		splitversion = (bb.data.getVar('PKGV', localdata, True) or
> "").replace('-', '+')
> >  		splitrelease = (bb.data.getVar('PKGR', localdata, True) or "") @@
> > -528,6 +531,39 @@ python write_specfile () {
> >  		if pkg == d.getVar("PN", True):
> >  			splitrprovides = splitrprovides + " " +
> > (d.getVar('ALTERNATIVE_LINK', True) or '') + " " +
> > (d.getVar('ALTERNATIVE_LINKS', True) or '')
> >
> > +		package_arch = bb.data.getVar('PACKAGE_ARCH', localdata, True)
> > +
> > +		splitrprovides = splitrprovides + " " + splitname + "." + defaulttune
> > +		if package_arch != "all":
> > +			pattern = '\([^()]*\)'
> > +			prog = re.compile(pattern)
> > +
> > +			str_list = [splitrdepends, splitrrecommends, splitrsuggests]
> > +			for e in range(len(str_list)):
> > +				brackets = prog.findall(str_list[e])
> > +				for i in range(len(brackets)):
> > +					str_list[e] = str_list[e].replace(brackets[i],
> "#BRACKETS"+str(i)+"#")
> > +				tmp = ""
> > +				for i in str_list[e].split():
> > +					if i.startswith("#BRACKETS"):
> > +						tmp += " " + str(i)
> > +						continue
> > +					tmp += " " + str(i) + "." + defaulttune
> > +				str_list[e] = tmp
> > +				for i in range(len(brackets)):
> > +					str_list[e] = str_list[e].replace("#BRACKETS"+str(i)+"#",
> > +brackets[i])
> > +
> > +			[splitrdepends, splitrrecommends, splitrsuggests] = str_list
> > +		else:
> > +			variants = (bb.data.getVar("MULTILIB_VARIANTS", localdata,
> True) or "").split()
> > +			for variant in variants:
> > +				tune = bb.data.getVar("DEFAULTTUNE_virtclass-multilib-" +
> variant, localdata, True) or ""
> > +				if tune:
> > +					splitrprovides = splitrprovides + " " + splitname + "." +
> tune
> > +			tune = bb.data.getVar("SAVED_DEFAULTTUNE", localdata, True)
> or ""
> > +			if tune:
> > +				splitrprovides = splitrprovides + " " + splitname + "." + tune
> > +
> >  		# Gather special src/first package data
> >  		if srcname == splitname:
> >  			srcrdepends    = splitrdepends
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Mark Hatle]

On 9/12/11 9:24 PM, Xu, Dongxiao wrote:
> Hi Mark,
> 
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, September 12, 2011 10:52 PM
>> To: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info in rpm
>> spec file
>>
>> This patch is incorrect.  Architectural information should not be in the
>> dependencies within RPM packages.
>>
>> RPM is expected to find the proper version of a package to install based on the
>> existing dependency information.  I'm in the process of investigating why
>> certain items are not found properly.
> 
> Take "task-core-boot-1.0-r8.qemux86_64.rpm" as an example, and it has dependency on tinylogin, how can it determine whether it is depends on " tinylogin-1.4-r7.x86_64.rpm" or "tinylogin-1.4-r7.x86.rpm".

In this case, it should not matter which one it uses.  If the dependency is on
"tinylogin", then either of them fulfills the dependency.  RPM should be
selecting which one to bring in using it's internal policy manager.  (I believe
the default is that 64-bit wins...)

For libraries where it does matter, the dependency system should already be
finding the correct architecture for the library.

This does raise an issue in my mind though.  Is an architecture for "tasks"
justifiable?  Why isn't the task-core-boot an all or noarch package?

Is there any difference between a task-core-boot and "lib32-task-core-boot"?

Should we expect a difference between the two?

--Mark

> Thanks,
> Dongxiao
> 
>>
>> --Mark
>>
>> On 9/12/11 3:33 AM, Dongxiao Xu wrote:
>>> For supporting multilib, architecture information is needed in package
>>> require/provide/suggest/recommend fields.
>>>
>>> Use DEFAULTTUNE value as the postfix.
>>>
>>> For "all" arch recipe, it requires "all" arch recipe with no postfix,
>>> but provides all possible multilib archs.
>>>
>>> For example, qemu-config:
>>>
>>> Requires: rsync
>>> Requires: update-rc.d
>>> Requires: task-core-nfs-server
>>> Requires: distcc
>>> Requires: oprofileui-server
>>> Requires: dbus-x11
>>> Requires: bash
>>> Provides: qemu-config.x86
>>> Provides: qemu-config.x86-64
>>>
>>> For other recipe like zlib:
>>>
>>> Requires: libc6.x86-64 >= 2.13
>>> Provides: zlib.x86-64
>>>
>>> [YOCTO #1457]
>>>
>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>> ---
>>>  meta/classes/multilib.bbclass    |    1 +
>>>  meta/classes/package_rpm.bbclass |   36
>> ++++++++++++++++++++++++++++++++++++
>>>  2 files changed, 37 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/meta/classes/multilib.bbclass
>>> b/meta/classes/multilib.bbclass index 583d76b..76c86b2 100644
>>> --- a/meta/classes/multilib.bbclass
>>> +++ b/meta/classes/multilib.bbclass
>>> @@ -23,6 +23,7 @@ python multilib_virtclass_handler () {
>>>      e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
>>>      e.data.setVar("SHLIBSDIR_virtclass-multilib-" +
>> variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
>>>      e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant,
>>> e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
>>> +    e.data.setVar("SAVED_DEFAULTTUNE",
>> e.data.getVar("DEFAULTTUNE",
>>> + True))
>>>      e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) +
>>> override)  }
>>>
>>> diff --git a/meta/classes/package_rpm.bbclass
>>> b/meta/classes/package_rpm.bbclass
>>> index 9ef1acd..ea0a079 100644
>>> --- a/meta/classes/package_rpm.bbclass
>>> +++ b/meta/classes/package_rpm.bbclass
>>> @@ -350,6 +350,7 @@ package_install_internal_rpm () {  python
>>> write_specfile () {
>>>  	import textwrap
>>>  	import oe.packagedata
>>> +	import re
>>>
>>>  	# We need a simple way to remove the MLPREFIX from the package name,
>>>  	# and dependency information...
>>> @@ -498,6 +499,8 @@ python write_specfile () {
>>>
>>>  		splitname    = strip_multilib(pkgname, d)
>>>
>>> +		defaulttune = bb.data.getVar('DEFAULTTUNE', localdata, True)
>>> +
>>>  		splitsummary = (bb.data.getVar('SUMMARY', localdata, True) or
>> bb.data.getVar('DESCRIPTION', localdata, True) or ".")
>>>  		splitversion = (bb.data.getVar('PKGV', localdata, True) or
>> "").replace('-', '+')
>>>  		splitrelease = (bb.data.getVar('PKGR', localdata, True) or "") @@
>>> -528,6 +531,39 @@ python write_specfile () {
>>>  		if pkg == d.getVar("PN", True):
>>>  			splitrprovides = splitrprovides + " " +
>>> (d.getVar('ALTERNATIVE_LINK', True) or '') + " " +
>>> (d.getVar('ALTERNATIVE_LINKS', True) or '')
>>>
>>> +		package_arch = bb.data.getVar('PACKAGE_ARCH', localdata, True)
>>> +
>>> +		splitrprovides = splitrprovides + " " + splitname + "." + defaulttune
>>> +		if package_arch != "all":
>>> +			pattern = '\([^()]*\)'
>>> +			prog = re.compile(pattern)
>>> +
>>> +			str_list = [splitrdepends, splitrrecommends, splitrsuggests]
>>> +			for e in range(len(str_list)):
>>> +				brackets = prog.findall(str_list[e])
>>> +				for i in range(len(brackets)):
>>> +					str_list[e] = str_list[e].replace(brackets[i],
>> "#BRACKETS"+str(i)+"#")
>>> +				tmp = ""
>>> +				for i in str_list[e].split():
>>> +					if i.startswith("#BRACKETS"):
>>> +						tmp += " " + str(i)
>>> +						continue
>>> +					tmp += " " + str(i) + "." + defaulttune
>>> +				str_list[e] = tmp
>>> +				for i in range(len(brackets)):
>>> +					str_list[e] = str_list[e].replace("#BRACKETS"+str(i)+"#",
>>> +brackets[i])
>>> +
>>> +			[splitrdepends, splitrrecommends, splitrsuggests] = str_list
>>> +		else:
>>> +			variants = (bb.data.getVar("MULTILIB_VARIANTS", localdata,
>> True) or "").split()
>>> +			for variant in variants:
>>> +				tune = bb.data.getVar("DEFAULTTUNE_virtclass-multilib-" +
>> variant, localdata, True) or ""
>>> +				if tune:
>>> +					splitrprovides = splitrprovides + " " + splitname + "." +
>> tune
>>> +			tune = bb.data.getVar("SAVED_DEFAULTTUNE", localdata, True)
>> or ""
>>> +			if tune:
>>> +				splitrprovides = splitrprovides + " " + splitname + "." + tune
>>> +
>>>  		# Gather special src/first package data
>>>  		if srcname == splitname:
>>>  			srcrdepends    = splitrdepends
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Xu, Dongxiao]

Hi Mark,

> -----Original Message-----
> From: Mark Hatle [mailto:mark.hatle@windriver.com]
> Sent: Tuesday, September 13, 2011 11:29 PM
> To: Xu, Dongxiao
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info in rpm
> spec file
> 
> On 9/12/11 9:24 PM, Xu, Dongxiao wrote:
> > Hi Mark,
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> >> Of Mark Hatle
> >> Sent: Monday, September 12, 2011 10:52 PM
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info
> >> in rpm spec file
> >>
> >> This patch is incorrect.  Architectural information should not be in
> >> the dependencies within RPM packages.
> >>
> >> RPM is expected to find the proper version of a package to install
> >> based on the existing dependency information.  I'm in the process of
> >> investigating why certain items are not found properly.
> >
> > Take "task-core-boot-1.0-r8.qemux86_64.rpm" as an example, and it has
> dependency on tinylogin, how can it determine whether it is depends on "
> tinylogin-1.4-r7.x86_64.rpm" or "tinylogin-1.4-r7.x86.rpm".
> 
> In this case, it should not matter which one it uses.  If the dependency is on
> "tinylogin", then either of them fulfills the dependency.  RPM should be
> selecting which one to bring in using it's internal policy manager.  (I believe
> the default is that 64-bit wins...)

I think it DOES matter on which one it uses. Thinking the case that if a user wants to build a pure 64 bit system, and if it could not correctly choose the 64 bit of tinylogin, then his system will be contaminated with 32bit programs/libraries. 

Also during my testings, I found rpm will select the "wrong" version (x86 tinylogin).

Thanks,
Dongxiao

> 
> For libraries where it does matter, the dependency system should already be
> finding the correct architecture for the library.
> 
> This does raise an issue in my mind though.  Is an architecture for "tasks"
> justifiable?  Why isn't the task-core-boot an all or noarch package?
> 
> Is there any difference between a task-core-boot and "lib32-task-core-boot"?
> 
> Should we expect a difference between the two?
> 
> --Mark
> 
> > Thanks,
> > Dongxiao
> >
> >>
> >> --Mark
> >>
> >> On 9/12/11 3:33 AM, Dongxiao Xu wrote:
> >>> For supporting multilib, architecture information is needed in
> >>> package require/provide/suggest/recommend fields.
> >>>
> >>> Use DEFAULTTUNE value as the postfix.
> >>>
> >>> For "all" arch recipe, it requires "all" arch recipe with no
> >>> postfix, but provides all possible multilib archs.
> >>>
> >>> For example, qemu-config:
> >>>
> >>> Requires: rsync
> >>> Requires: update-rc.d
> >>> Requires: task-core-nfs-server
> >>> Requires: distcc
> >>> Requires: oprofileui-server
> >>> Requires: dbus-x11
> >>> Requires: bash
> >>> Provides: qemu-config.x86
> >>> Provides: qemu-config.x86-64
> >>>
> >>> For other recipe like zlib:
> >>>
> >>> Requires: libc6.x86-64 >= 2.13
> >>> Provides: zlib.x86-64
> >>>
> >>> [YOCTO #1457]
> >>>
> >>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> >>> ---
> >>>  meta/classes/multilib.bbclass    |    1 +
> >>>  meta/classes/package_rpm.bbclass |   36
> >> ++++++++++++++++++++++++++++++++++++
> >>>  2 files changed, 37 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/meta/classes/multilib.bbclass
> >>> b/meta/classes/multilib.bbclass index 583d76b..76c86b2 100644
> >>> --- a/meta/classes/multilib.bbclass
> >>> +++ b/meta/classes/multilib.bbclass
> >>> @@ -23,6 +23,7 @@ python multilib_virtclass_handler () {
> >>>      e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> >>>      e.data.setVar("SHLIBSDIR_virtclass-multilib-" +
> >> variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
> >>>      e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant,
> >>> e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
> >>> +    e.data.setVar("SAVED_DEFAULTTUNE",
> >> e.data.getVar("DEFAULTTUNE",
> >>> + True))
> >>>      e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) +
> >>> override)  }
> >>>
> >>> diff --git a/meta/classes/package_rpm.bbclass
> >>> b/meta/classes/package_rpm.bbclass
> >>> index 9ef1acd..ea0a079 100644
> >>> --- a/meta/classes/package_rpm.bbclass
> >>> +++ b/meta/classes/package_rpm.bbclass
> >>> @@ -350,6 +350,7 @@ package_install_internal_rpm () {  python
> >>> write_specfile () {
> >>>  	import textwrap
> >>>  	import oe.packagedata
> >>> +	import re
> >>>
> >>>  	# We need a simple way to remove the MLPREFIX from the package
> name,
> >>>  	# and dependency information...
> >>> @@ -498,6 +499,8 @@ python write_specfile () {
> >>>
> >>>  		splitname    = strip_multilib(pkgname, d)
> >>>
> >>> +		defaulttune = bb.data.getVar('DEFAULTTUNE', localdata, True)
> >>> +
> >>>  		splitsummary = (bb.data.getVar('SUMMARY', localdata, True) or
> >> bb.data.getVar('DESCRIPTION', localdata, True) or ".")
> >>>  		splitversion = (bb.data.getVar('PKGV', localdata, True) or
> >> "").replace('-', '+')
> >>>  		splitrelease = (bb.data.getVar('PKGR', localdata, True) or "")
> @@
> >>> -528,6 +531,39 @@ python write_specfile () {
> >>>  		if pkg == d.getVar("PN", True):
> >>>  			splitrprovides = splitrprovides + " " +
> >>> (d.getVar('ALTERNATIVE_LINK', True) or '') + " " +
> >>> (d.getVar('ALTERNATIVE_LINKS', True) or '')
> >>>
> >>> +		package_arch = bb.data.getVar('PACKAGE_ARCH', localdata,
> True)
> >>> +
> >>> +		splitrprovides = splitrprovides + " " + splitname + "." +
> defaulttune
> >>> +		if package_arch != "all":
> >>> +			pattern = '\([^()]*\)'
> >>> +			prog = re.compile(pattern)
> >>> +
> >>> +			str_list = [splitrdepends, splitrrecommends, splitrsuggests]
> >>> +			for e in range(len(str_list)):
> >>> +				brackets = prog.findall(str_list[e])
> >>> +				for i in range(len(brackets)):
> >>> +					str_list[e] = str_list[e].replace(brackets[i],
> >> "#BRACKETS"+str(i)+"#")
> >>> +				tmp = ""
> >>> +				for i in str_list[e].split():
> >>> +					if i.startswith("#BRACKETS"):
> >>> +						tmp += " " + str(i)
> >>> +						continue
> >>> +					tmp += " " + str(i) + "." + defaulttune
> >>> +				str_list[e] = tmp
> >>> +				for i in range(len(brackets)):
> >>> +					str_list[e] =
> str_list[e].replace("#BRACKETS"+str(i)+"#",
> >>> +brackets[i])
> >>> +
> >>> +			[splitrdepends, splitrrecommends, splitrsuggests] = str_list
> >>> +		else:
> >>> +			variants = (bb.data.getVar("MULTILIB_VARIANTS",
> localdata,
> >> True) or "").split()
> >>> +			for variant in variants:
> >>> +				tune =
> bb.data.getVar("DEFAULTTUNE_virtclass-multilib-" +
> >> variant, localdata, True) or ""
> >>> +				if tune:
> >>> +					splitrprovides = splitrprovides + " " + splitname +
> "." +
> >> tune
> >>> +			tune = bb.data.getVar("SAVED_DEFAULTTUNE", localdata,
> True)
> >> or ""
> >>> +			if tune:
> >>> +				splitrprovides = splitrprovides + " " + splitname + "." +
> tune
> >>> +
> >>>  		# Gather special src/first package data
> >>>  		if srcname == splitname:
> >>>  			srcrdepends    = splitrdepends
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Mark Hatle]

On 9/13/11 10:41 AM, Xu, Dongxiao wrote:
> Hi Mark,
> 
>> -----Original Message-----
>> From: Mark Hatle [mailto:mark.hatle@windriver.com]
>> Sent: Tuesday, September 13, 2011 11:29 PM
>> To: Xu, Dongxiao
>> Cc: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info in rpm
>> spec file
>>
>> On 9/12/11 9:24 PM, Xu, Dongxiao wrote:
>>> Hi Mark,
>>>
>>>> -----Original Message-----
>>>> From: openembedded-core-bounces@lists.openembedded.org
>>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
>>>> Of Mark Hatle
>>>> Sent: Monday, September 12, 2011 10:52 PM
>>>> To: openembedded-core@lists.openembedded.org
>>>> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info
>>>> in rpm spec file
>>>>
>>>> This patch is incorrect.  Architectural information should not be in
>>>> the dependencies within RPM packages.
>>>>
>>>> RPM is expected to find the proper version of a package to install
>>>> based on the existing dependency information.  I'm in the process of
>>>> investigating why certain items are not found properly.
>>>
>>> Take "task-core-boot-1.0-r8.qemux86_64.rpm" as an example, and it has
>> dependency on tinylogin, how can it determine whether it is depends on "
>> tinylogin-1.4-r7.x86_64.rpm" or "tinylogin-1.4-r7.x86.rpm".
>>
>> In this case, it should not matter which one it uses.  If the dependency is on
>> "tinylogin", then either of them fulfills the dependency.  RPM should be
>> selecting which one to bring in using it's internal policy manager.  (I believe
>> the default is that 64-bit wins...)
> 
> I think it DOES matter on which one it uses. Thinking the case that if a user wants to build a pure 64 bit system, and if it could not correctly choose the 64 bit of tinylogin, then his system will be contaminated with 32bit programs/libraries. 

With the current way oe-core processes packages into images it uses the
dependencies.. so no matter what you have built you are only guaranteed that the
resulting image contains that final dependency and whatever is needed to make it
"work".  There is nothing that says (today) that you will get a pure 64-bit or
32-bit system -- other then as an artifact of only building 32-bit or 64-bit
software.

There are different strategies we can use to deal with these situations.

1) Resolve the "base" non-multilib system "first", then augment it with the
multilib components.  This results in a "base system" + alternative packages.

2) Resolve the system as whole, including multilibs, and use the policy
components to determine the "best match".  (best match may not be working right
today)  This results in a system based purely on dependency matches.

Either way, our current implementation doesn't quite match either of them.
We're closer to the second version of the implementation today....

If the base system approach is what we want, vs the pure dependency based
system, then we will need to change the way the dependencies are being resolved
and the ordering of the resolution in the packages_rpm.bbclass (or
rootfs_rpm.bbclass).  Basically:

*) take the list of dependencies and filter out any multilibs, and only scan
them against the base archs.

*) add to that resolution any multilib components that had been filtered out and
scan against the all archs.

....

*) install as we do today

--Mark

> Also during my testings, I found rpm will select the "wrong" version (x86 tinylogin).
> 
> Thanks,
> Dongxiao
> 
>>
>> For libraries where it does matter, the dependency system should already be
>> finding the correct architecture for the library.
>>
>> This does raise an issue in my mind though.  Is an architecture for "tasks"
>> justifiable?  Why isn't the task-core-boot an all or noarch package?
>>
>> Is there any difference between a task-core-boot and "lib32-task-core-boot"?
>>
>> Should we expect a difference between the two?
>>
>> --Mark
>>
>>> Thanks,
>>> Dongxiao
>>>
>>>>
>>>> --Mark
>>>>
>>>> On 9/12/11 3:33 AM, Dongxiao Xu wrote:
>>>>> For supporting multilib, architecture information is needed in
>>>>> package require/provide/suggest/recommend fields.
>>>>>
>>>>> Use DEFAULTTUNE value as the postfix.
>>>>>
>>>>> For "all" arch recipe, it requires "all" arch recipe with no
>>>>> postfix, but provides all possible multilib archs.
>>>>>
>>>>> For example, qemu-config:
>>>>>
>>>>> Requires: rsync
>>>>> Requires: update-rc.d
>>>>> Requires: task-core-nfs-server
>>>>> Requires: distcc
>>>>> Requires: oprofileui-server
>>>>> Requires: dbus-x11
>>>>> Requires: bash
>>>>> Provides: qemu-config.x86
>>>>> Provides: qemu-config.x86-64
>>>>>
>>>>> For other recipe like zlib:
>>>>>
>>>>> Requires: libc6.x86-64 >= 2.13
>>>>> Provides: zlib.x86-64
>>>>>
>>>>> [YOCTO #1457]
>>>>>
>>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>>>> ---
>>>>>  meta/classes/multilib.bbclass    |    1 +
>>>>>  meta/classes/package_rpm.bbclass |   36
>>>> ++++++++++++++++++++++++++++++++++++
>>>>>  2 files changed, 37 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/meta/classes/multilib.bbclass
>>>>> b/meta/classes/multilib.bbclass index 583d76b..76c86b2 100644
>>>>> --- a/meta/classes/multilib.bbclass
>>>>> +++ b/meta/classes/multilib.bbclass
>>>>> @@ -23,6 +23,7 @@ python multilib_virtclass_handler () {
>>>>>      e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
>>>>>      e.data.setVar("SHLIBSDIR_virtclass-multilib-" +
>>>> variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
>>>>>      e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant,
>>>>> e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
>>>>> +    e.data.setVar("SAVED_DEFAULTTUNE",
>>>> e.data.getVar("DEFAULTTUNE",
>>>>> + True))
>>>>>      e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) +
>>>>> override)  }
>>>>>
>>>>> diff --git a/meta/classes/package_rpm.bbclass
>>>>> b/meta/classes/package_rpm.bbclass
>>>>> index 9ef1acd..ea0a079 100644
>>>>> --- a/meta/classes/package_rpm.bbclass
>>>>> +++ b/meta/classes/package_rpm.bbclass
>>>>> @@ -350,6 +350,7 @@ package_install_internal_rpm () {  python
>>>>> write_specfile () {
>>>>>  	import textwrap
>>>>>  	import oe.packagedata
>>>>> +	import re
>>>>>
>>>>>  	# We need a simple way to remove the MLPREFIX from the package
>> name,
>>>>>  	# and dependency information...
>>>>> @@ -498,6 +499,8 @@ python write_specfile () {
>>>>>
>>>>>  		splitname    = strip_multilib(pkgname, d)
>>>>>
>>>>> +		defaulttune = bb.data.getVar('DEFAULTTUNE', localdata, True)
>>>>> +
>>>>>  		splitsummary = (bb.data.getVar('SUMMARY', localdata, True) or
>>>> bb.data.getVar('DESCRIPTION', localdata, True) or ".")
>>>>>  		splitversion = (bb.data.getVar('PKGV', localdata, True) or
>>>> "").replace('-', '+')
>>>>>  		splitrelease = (bb.data.getVar('PKGR', localdata, True) or "")
>> @@
>>>>> -528,6 +531,39 @@ python write_specfile () {
>>>>>  		if pkg == d.getVar("PN", True):
>>>>>  			splitrprovides = splitrprovides + " " +
>>>>> (d.getVar('ALTERNATIVE_LINK', True) or '') + " " +
>>>>> (d.getVar('ALTERNATIVE_LINKS', True) or '')
>>>>>
>>>>> +		package_arch = bb.data.getVar('PACKAGE_ARCH', localdata,
>> True)
>>>>> +
>>>>> +		splitrprovides = splitrprovides + " " + splitname + "." +
>> defaulttune
>>>>> +		if package_arch != "all":
>>>>> +			pattern = '\([^()]*\)'
>>>>> +			prog = re.compile(pattern)
>>>>> +
>>>>> +			str_list = [splitrdepends, splitrrecommends, splitrsuggests]
>>>>> +			for e in range(len(str_list)):
>>>>> +				brackets = prog.findall(str_list[e])
>>>>> +				for i in range(len(brackets)):
>>>>> +					str_list[e] = str_list[e].replace(brackets[i],
>>>> "#BRACKETS"+str(i)+"#")
>>>>> +				tmp = ""
>>>>> +				for i in str_list[e].split():
>>>>> +					if i.startswith("#BRACKETS"):
>>>>> +						tmp += " " + str(i)
>>>>> +						continue
>>>>> +					tmp += " " + str(i) + "." + defaulttune
>>>>> +				str_list[e] = tmp
>>>>> +				for i in range(len(brackets)):
>>>>> +					str_list[e] =
>> str_list[e].replace("#BRACKETS"+str(i)+"#",
>>>>> +brackets[i])
>>>>> +
>>>>> +			[splitrdepends, splitrrecommends, splitrsuggests] = str_list
>>>>> +		else:
>>>>> +			variants = (bb.data.getVar("MULTILIB_VARIANTS",
>> localdata,
>>>> True) or "").split()
>>>>> +			for variant in variants:
>>>>> +				tune =
>> bb.data.getVar("DEFAULTTUNE_virtclass-multilib-" +
>>>> variant, localdata, True) or ""
>>>>> +				if tune:
>>>>> +					splitrprovides = splitrprovides + " " + splitname +
>> "." +
>>>> tune
>>>>> +			tune = bb.data.getVar("SAVED_DEFAULTTUNE", localdata,
>> True)
>>>> or ""
>>>>> +			if tune:
>>>>> +				splitrprovides = splitrprovides + " " + splitname + "." +
>> tune
>>>>> +
>>>>>  		# Gather special src/first package data
>>>>>  		if srcname == splitname:
>>>>>  			srcrdepends    = splitrdepends
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 

Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Xu, Dongxiao]

Hi Mark,

> -----Original Message-----
> From: Mark Hatle [mailto:mark.hatle@windriver.com]
> Sent: Tuesday, September 13, 2011 11:59 PM
> To: Xu, Dongxiao
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info in rpm
> spec file
> 
> On 9/13/11 10:41 AM, Xu, Dongxiao wrote:
> > Hi Mark,
> >
> >> -----Original Message-----
> >> From: Mark Hatle [mailto:mark.hatle@windriver.com]
> >> Sent: Tuesday, September 13, 2011 11:29 PM
> >> To: Xu, Dongxiao
> >> Cc: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture info
> >> in rpm spec file
> >>
> >> On 9/12/11 9:24 PM, Xu, Dongxiao wrote:
> >>> Hi Mark,
> >>>
> >>>> -----Original Message-----
> >>>> From: openembedded-core-bounces@lists.openembedded.org
> >>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On
> Behalf
> >>>> Of Mark Hatle
> >>>> Sent: Monday, September 12, 2011 10:52 PM
> >>>> To: openembedded-core@lists.openembedded.org
> >>>> Subject: Re: [OE-core] [PATCH 1/3] package_rpm: add architecture
> >>>> info in rpm spec file
> >>>>
> >>>> This patch is incorrect.  Architectural information should not be
> >>>> in the dependencies within RPM packages.
> >>>>
> >>>> RPM is expected to find the proper version of a package to install
> >>>> based on the existing dependency information.  I'm in the process
> >>>> of investigating why certain items are not found properly.
> >>>
> >>> Take "task-core-boot-1.0-r8.qemux86_64.rpm" as an example, and it
> >>> has
> >> dependency on tinylogin, how can it determine whether it is depends on "
> >> tinylogin-1.4-r7.x86_64.rpm" or "tinylogin-1.4-r7.x86.rpm".
> >>
> >> In this case, it should not matter which one it uses.  If the
> >> dependency is on "tinylogin", then either of them fulfills the
> >> dependency.  RPM should be selecting which one to bring in using it's
> >> internal policy manager.  (I believe the default is that 64-bit
> >> wins...)
> >
> > I think it DOES matter on which one it uses. Thinking the case that if a user
> wants to build a pure 64 bit system, and if it could not correctly choose the 64
> bit of tinylogin, then his system will be contaminated with 32bit
> programs/libraries.
> 
> With the current way oe-core processes packages into images it uses the
> dependencies.. so no matter what you have built you are only guaranteed that
> the resulting image contains that final dependency and whatever is needed to
> make it "work".  There is nothing that says (today) that you will get a pure
> 64-bit or 32-bit system -- other then as an artifact of only building 32-bit or
> 64-bit software.

Let me take another case as an example during my debugging to this issue.

Thinking that you have built out an base qemux86-64 image, and several lib32 multilib packages. Due to the wrong selection when doing RPM, we have several packages (like libgtk), which need x86-64 version installed, however they are replace by 32bit packages. The do_rootfs process succeeded, but when booting the image, some Xserver programs fail to find /usr/lib64/libgtk.so, because in the system only /usr/lib/libgtk.so is installed, which caused the X start failure.

> 
> There are different strategies we can use to deal with these situations.
> 
> 1) Resolve the "base" non-multilib system "first", then augment it with the
> multilib components.  This results in a "base system" + alternative packages.
> 
> 2) Resolve the system as whole, including multilibs, and use the policy
> components to determine the "best match".  (best match may not be working
> right
> today)  This results in a system based purely on dependency matches.
> 
> Either way, our current implementation doesn't quite match either of them.
> We're closer to the second version of the implementation today....
> 
> If the base system approach is what we want, vs the pure dependency based
> system, then we will need to change the way the dependencies are being
> resolved and the ordering of the resolution in the packages_rpm.bbclass (or
> rootfs_rpm.bbclass).  Basically:
> 
> *) take the list of dependencies and filter out any multilibs, and only scan them
> against the base archs.
> 
> *) add to that resolution any multilib components that had been filtered out
> and scan against the all archs.
> 
> ....
> 
> *) install as we do today

I ever tried the second approach to fix the problem, however it failed.

I split the installation into two parts as you mentioned, first part is to install the base arch packages, and it does succeed. The second part is to install resolution to multilib components, when calculating the dependency, we will find "package xxx is already installed" error will be detected again by the "justdb" installation. I think there are wrong RPM dependency when installing lib32 multilib packages. showed as follows:

Processing locale-base-en-us...
Processing locale-base-en-gb...
Processing task-core-boot...
Processing task-core-apps-console...
Processing task-core-ssh-dropbear...
Processing task-core-apps-x11-pimlico...
Processing task-core-x11-sato...
Processing zypper...
Processing task-core-x11-base...
Processing task-core-apps-x11-games...
Processing task-core-apps-x11-core...
Processing task-base-extended...
Processing rpm...
Manifest: /distro/dongxiao/build-ml6/tmp/work/qemux86_64-poky-linux/core-image-sato-1.0-r0/rootfs/install/install.manifest
Preparing...                ##################################################
libc6                       ##################################################
update-rc.d-dbg             ##################################################
gst-meta-audio              ##################################################
pciutils-ids                ##################################################
...
...
Processing lib32-connman-gnome...
Processing lib32-task-base-3g...
Processing lib32-task-base-wifi...
Processing lib32-task-base-bluetooth...
Manifest: /distro/dongxiao/build-ml6/tmp/work/qemux86_64-poky-linux/core-image-sato-1.0-r0/rootfs/install/install_multilib.manifest
Preparing...                ##################################################
error: Install/Erase problems:
        package libc6-2.13-r14+svnr14157.x86_64 is already installed
        package update-rc.d-dbg-0.7-r4.all is already installed
        package gst-meta-audio-0.10-r10.x86_64 is already installed
        package pciutils-ids-3.1.7-r2.x86_64 is already installed
        package udev-extraconf-0.0-r1.x86_64 is already installed
...

Thanks,
Dongxiao

> 
> --Mark
> 
> > Also during my testings, I found rpm will select the "wrong" version (x86
> tinylogin).
> >
> > Thanks,
> > Dongxiao
> >
> >>
> >> For libraries where it does matter, the dependency system should
> >> already be finding the correct architecture for the library.
> >>
> >> This does raise an issue in my mind though.  Is an architecture for "tasks"
> >> justifiable?  Why isn't the task-core-boot an all or noarch package?
> >>
> >> Is there any difference between a task-core-boot and
> "lib32-task-core-boot"?
> >>
> >> Should we expect a difference between the two?
> >>
> >> --Mark
> >>
> >>> Thanks,
> >>> Dongxiao
> >>>
> >>>>
> >>>> --Mark
> >>>>
> >>>> On 9/12/11 3:33 AM, Dongxiao Xu wrote:
> >>>>> For supporting multilib, architecture information is needed in
> >>>>> package require/provide/suggest/recommend fields.
> >>>>>
> >>>>> Use DEFAULTTUNE value as the postfix.
> >>>>>
> >>>>> For "all" arch recipe, it requires "all" arch recipe with no
> >>>>> postfix, but provides all possible multilib archs.
> >>>>>
> >>>>> For example, qemu-config:
> >>>>>
> >>>>> Requires: rsync
> >>>>> Requires: update-rc.d
> >>>>> Requires: task-core-nfs-server
> >>>>> Requires: distcc
> >>>>> Requires: oprofileui-server
> >>>>> Requires: dbus-x11
> >>>>> Requires: bash
> >>>>> Provides: qemu-config.x86
> >>>>> Provides: qemu-config.x86-64
> >>>>>
> >>>>> For other recipe like zlib:
> >>>>>
> >>>>> Requires: libc6.x86-64 >= 2.13
> >>>>> Provides: zlib.x86-64
> >>>>>
> >>>>> [YOCTO #1457]
> >>>>>
> >>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> >>>>> ---
> >>>>>  meta/classes/multilib.bbclass    |    1 +
> >>>>>  meta/classes/package_rpm.bbclass |   36
> >>>> ++++++++++++++++++++++++++++++++++++
> >>>>>  2 files changed, 37 insertions(+), 0 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/classes/multilib.bbclass
> >>>>> b/meta/classes/multilib.bbclass index 583d76b..76c86b2 100644
> >>>>> --- a/meta/classes/multilib.bbclass
> >>>>> +++ b/meta/classes/multilib.bbclass
> >>>>> @@ -23,6 +23,7 @@ python multilib_virtclass_handler () {
> >>>>>      e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> >>>>>      e.data.setVar("SHLIBSDIR_virtclass-multilib-" +
> >>>> variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
> >>>>>      e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant,
> >>>>> e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
> >>>>> +    e.data.setVar("SAVED_DEFAULTTUNE",
> >>>> e.data.getVar("DEFAULTTUNE",
> >>>>> + True))
> >>>>>      e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False)
> >>>>> +
> >>>>> override)  }
> >>>>>
> >>>>> diff --git a/meta/classes/package_rpm.bbclass
> >>>>> b/meta/classes/package_rpm.bbclass
> >>>>> index 9ef1acd..ea0a079 100644
> >>>>> --- a/meta/classes/package_rpm.bbclass
> >>>>> +++ b/meta/classes/package_rpm.bbclass
> >>>>> @@ -350,6 +350,7 @@ package_install_internal_rpm () {  python
> >>>>> write_specfile () {
> >>>>>  	import textwrap
> >>>>>  	import oe.packagedata
> >>>>> +	import re
> >>>>>
> >>>>>  	# We need a simple way to remove the MLPREFIX from the package
> >> name,
> >>>>>  	# and dependency information...
> >>>>> @@ -498,6 +499,8 @@ python write_specfile () {
> >>>>>
> >>>>>  		splitname    = strip_multilib(pkgname, d)
> >>>>>
> >>>>> +		defaulttune = bb.data.getVar('DEFAULTTUNE', localdata, True)
> >>>>> +
> >>>>>  		splitsummary = (bb.data.getVar('SUMMARY', localdata, True) or
> >>>> bb.data.getVar('DESCRIPTION', localdata, True) or ".")
> >>>>>  		splitversion = (bb.data.getVar('PKGV', localdata, True) or
> >>>> "").replace('-', '+')
> >>>>>  		splitrelease = (bb.data.getVar('PKGR', localdata, True) or "")
> >> @@
> >>>>> -528,6 +531,39 @@ python write_specfile () {
> >>>>>  		if pkg == d.getVar("PN", True):
> >>>>>  			splitrprovides = splitrprovides + " " +
> >>>>> (d.getVar('ALTERNATIVE_LINK', True) or '') + " " +
> >>>>> (d.getVar('ALTERNATIVE_LINKS', True) or '')
> >>>>>
> >>>>> +		package_arch = bb.data.getVar('PACKAGE_ARCH', localdata,
> >> True)
> >>>>> +
> >>>>> +		splitrprovides = splitrprovides + " " + splitname + "." +
> >> defaulttune
> >>>>> +		if package_arch != "all":
> >>>>> +			pattern = '\([^()]*\)'
> >>>>> +			prog = re.compile(pattern)
> >>>>> +
> >>>>> +			str_list = [splitrdepends, splitrrecommends, splitrsuggests]
> >>>>> +			for e in range(len(str_list)):
> >>>>> +				brackets = prog.findall(str_list[e])
> >>>>> +				for i in range(len(brackets)):
> >>>>> +					str_list[e] = str_list[e].replace(brackets[i],
> >>>> "#BRACKETS"+str(i)+"#")
> >>>>> +				tmp = ""
> >>>>> +				for i in str_list[e].split():
> >>>>> +					if i.startswith("#BRACKETS"):
> >>>>> +						tmp += " " + str(i)
> >>>>> +						continue
> >>>>> +					tmp += " " + str(i) + "." + defaulttune
> >>>>> +				str_list[e] = tmp
> >>>>> +				for i in range(len(brackets)):
> >>>>> +					str_list[e] =
> >> str_list[e].replace("#BRACKETS"+str(i)+"#",
> >>>>> +brackets[i])
> >>>>> +
> >>>>> +			[splitrdepends, splitrrecommends, splitrsuggests] = str_list
> >>>>> +		else:
> >>>>> +			variants = (bb.data.getVar("MULTILIB_VARIANTS",
> >> localdata,
> >>>> True) or "").split()
> >>>>> +			for variant in variants:
> >>>>> +				tune =
> >> bb.data.getVar("DEFAULTTUNE_virtclass-multilib-" +
> >>>> variant, localdata, True) or ""
> >>>>> +				if tune:
> >>>>> +					splitrprovides = splitrprovides + " " + splitname +
> >> "." +
> >>>> tune
> >>>>> +			tune = bb.data.getVar("SAVED_DEFAULTTUNE", localdata,
> >> True)
> >>>> or ""
> >>>>> +			if tune:
> >>>>> +				splitrprovides = splitrprovides + " " + splitname + "." +
> >> tune
> >>>>> +
> >>>>>  		# Gather special src/first package data
> >>>>>  		if srcname == splitname:
> >>>>>  			srcrdepends    = splitrdepends
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Openembedded-core mailing list
> >>>> Openembedded-core@lists.openembedded.org
> >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-co
> >>>> re
> >

Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file

[Mark Hatle]

On 9/13/11 8:03 PM, Xu, Dongxiao wrote:
> Hi Mark,
> 

...trimming the thread a bit...

>>>>>> This patch is incorrect.  Architectural information should not be
>>>>>> in the dependencies within RPM packages.
>>>>>>
>>>>>> RPM is expected to find the proper version of a package to install
>>>>>> based on the existing dependency information.  I'm in the process
>>>>>> of investigating why certain items are not found properly.
>>>>>

> Let me take another case as an example during my debugging to this issue.
> 
> Thinking that you have built out an base qemux86-64 image, and several lib32 multilib packages. Due to the wrong selection when doing RPM, we have several packages (like libgtk), which need x86-64 version installed, however they are replace by 32bit packages. The do_rootfs process succeeded, but when booting the image, some Xserver programs fail to find /usr/lib64/libgtk.so, because in the system only /usr/lib/libgtk.so is installed, which caused the X start failure.

That is a completely different issue.  If applications need the 64-bit libraries
and the 32-bit ones are fulfilling the dependencies, then we have a dependency
mismatch.  Libraries should contain dependency information (within RPM) that
properly describe the ELF ABI as an artifact of the dependency generation.  This
is a defect we should be able to resolve in the package_rpm.bbclass.

I'll attempt to look into it today, unless someone beats me to it.

>>
>> There are different strategies we can use to deal with these situations.
>>
>> 1) Resolve the "base" non-multilib system "first", then augment it with the
>> multilib components.  This results in a "base system" + alternative packages.
>>
>> 2) Resolve the system as whole, including multilibs, and use the policy
>> components to determine the "best match".  (best match may not be working
>> right
>> today)  This results in a system based purely on dependency matches.
>>
>> Either way, our current implementation doesn't quite match either of them.
>> We're closer to the second version of the implementation today....
>>
>> If the base system approach is what we want, vs the pure dependency based
>> system, then we will need to change the way the dependencies are being
>> resolved and the ordering of the resolution in the packages_rpm.bbclass (or
>> rootfs_rpm.bbclass).  Basically:
>>
>> *) take the list of dependencies and filter out any multilibs, and only scan them
>> against the base archs.
>>
>> *) add to that resolution any multilib components that had been filtered out
>> and scan against the all archs.
>>
>> ....
>>
>> *) install as we do today
> 
> I ever tried the second approach to fix the problem, however it failed.
> 
> I split the installation into two parts as you mentioned, first part is to install the base arch packages, and it does succeed. The second part is to install resolution to multilib components, when calculating the dependency, we will find "package xxx is already installed" error will be detected again by the "justdb" installation. I think there are wrong RPM dependency when installing lib32 multilib packages. showed as follows:
> 
> Processing locale-base-en-us...
> Processing locale-base-en-gb...
> Processing task-core-boot...
> Processing task-core-apps-console...
> Processing task-core-ssh-dropbear...
> Processing task-core-apps-x11-pimlico...
> Processing task-core-x11-sato...
> Processing zypper...
> Processing task-core-x11-base...
> Processing task-core-apps-x11-games...
> Processing task-core-apps-x11-core...
> Processing task-base-extended...
> Processing rpm...
> Manifest: /distro/dongxiao/build-ml6/tmp/work/qemux86_64-poky-linux/core-image-sato-1.0-r0/rootfs/install/install.manifest
> Preparing...                ##################################################
> libc6                       ##################################################
> update-rc.d-dbg             ##################################################
> gst-meta-audio              ##################################################
> pciutils-ids                ##################################################
> ...
> ...
> Processing lib32-connman-gnome...
> Processing lib32-task-base-3g...
> Processing lib32-task-base-wifi...
> Processing lib32-task-base-bluetooth...
> Manifest: /distro/dongxiao/build-ml6/tmp/work/qemux86_64-poky-linux/core-image-sato-1.0-r0/rootfs/install/install_multilib.manifest
> Preparing...                ##################################################
> error: Install/Erase problems:
>         package libc6-2.13-r14+svnr14157.x86_64 is already installed
>         package update-rc.d-dbg-0.7-r4.all is already installed
>         package gst-meta-audio-0.10-r10.x86_64 is already installed
>         package pciutils-ids-3.1.7-r2.x86_64 is already installed
>         package udev-extraconf-0.0-r1.x86_64 is already installed
> ...

This is a bit strange.  It should have detected from the resolution code that
the item was already installed and doesn't need to be re-installed -- unless the
above ELF types are causing this issue as well as the one described above.

--Mark

[PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Dongxiao Xu]

Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
a lib32 version of rpm package will override a normal rpm package if
its PACKAGE_ARCH is ${MACHINE_ARCH}.

Define different deploy folder for multilib architectures to avoid the
confliction.

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 meta/classes/multilib.bbclass   |    5 +++++
 meta/classes/rootfs_rpm.bbclass |    4 +++-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 76c86b2..6ace1fe 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -77,4 +77,9 @@ python __anonymous () {
     multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
     multilib_map_variable("PACKAGE_INSTALL", variant, d)
     multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
+
+    package_arch = d.getVar("PACKAGE_ARCH", True)
+    machine_arch = d.getVar("MACHINE_ARCH", True)
+    if package_arch == machine_arch:
+        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
 }
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 135ca75..7936d77 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -218,7 +218,9 @@ python () {
             default_tune = localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
             if default_tune:
                 localdata.setVar("DEFAULTTUNE", default_tune)
-            ml_package_archs += localdata.getVar("PACKAGE_ARCHS", True) or ""
+            localdata.setVar("MACHINE_ARCH", eext[1] + "_" + localdata.getVar("MACHINE_ARCH", False))
+            package_archs = localdata.getVar("PACKAGE_ARCHS", True) or ""
+            ml_package_archs += " " + package_archs
             #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1], localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
     bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
 }
-- 
1.7.1

Re: [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Mark Hatle]

On 9/12/11 3:34 AM, Dongxiao Xu wrote:
> Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
> a lib32 version of rpm package will override a normal rpm package if
> its PACKAGE_ARCH is ${MACHINE_ARCH}.
> 
> Define different deploy folder for multilib architectures to avoid the
> confliction.

I'm not sure I understand here.  Within the deployment directory is a set of
directories for each RPM architecture.  Are you saying that we can get two
packages that have different contents but the same RPM architecture?

Can you give me an example of what is going wrong?

--Mark

> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> ---
>  meta/classes/multilib.bbclass   |    5 +++++
>  meta/classes/rootfs_rpm.bbclass |    4 +++-
>  2 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index 76c86b2..6ace1fe 100644
> --- a/meta/classes/multilib.bbclass
> +++ b/meta/classes/multilib.bbclass
> @@ -77,4 +77,9 @@ python __anonymous () {
>      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
>      multilib_map_variable("PACKAGE_INSTALL", variant, d)
>      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
> +
> +    package_arch = d.getVar("PACKAGE_ARCH", True)
> +    machine_arch = d.getVar("MACHINE_ARCH", True)
> +    if package_arch == machine_arch:
> +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
>  }
> diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
> index 135ca75..7936d77 100644
> --- a/meta/classes/rootfs_rpm.bbclass
> +++ b/meta/classes/rootfs_rpm.bbclass
> @@ -218,7 +218,9 @@ python () {
>              default_tune = localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
>              if default_tune:
>                  localdata.setVar("DEFAULTTUNE", default_tune)
> -            ml_package_archs += localdata.getVar("PACKAGE_ARCHS", True) or ""
> +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" + localdata.getVar("MACHINE_ARCH", False))
> +            package_archs = localdata.getVar("PACKAGE_ARCHS", True) or ""
> +            ml_package_archs += " " + package_archs
>              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1], localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
>      bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
>  }

Re: [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Xu, Dongxiao]

Hi Mark,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Monday, September 12, 2011 10:56 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under
> deploy/rpm
> 
> On 9/12/11 3:34 AM, Dongxiao Xu wrote:
> > Currently MACHINE_ARCH deploy folder is unique in multilib system,
> > thus a lib32 version of rpm package will override a normal rpm package
> > if its PACKAGE_ARCH is ${MACHINE_ARCH}.
> >
> > Define different deploy folder for multilib architectures to avoid the
> > confliction.
> 
> I'm not sure I understand here.  Within the deployment directory is a set of
> directories for each RPM architecture.  Are you saying that we can get two
> packages that have different contents but the same RPM architecture?
> 

Yes, for example the netbase recipe, which the PACKAGE_ARCH = MACHINE_ARCH. Both the normal version of netbase package and the lib32 version are named as "netbase-4.45-r1.qemux86_64.rpm" putting in tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them.

Thanks,
Dongxiao

> Can you give me an example of what is going wrong?
> 
> --Mark
> 
> > Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> > ---
> >  meta/classes/multilib.bbclass   |    5 +++++
> >  meta/classes/rootfs_rpm.bbclass |    4 +++-
> >  2 files changed, 8 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/classes/multilib.bbclass
> > b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644
> > --- a/meta/classes/multilib.bbclass
> > +++ b/meta/classes/multilib.bbclass
> > @@ -77,4 +77,9 @@ python __anonymous () {
> >      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
> >      multilib_map_variable("PACKAGE_INSTALL", variant, d)
> >      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
> > +
> > +    package_arch = d.getVar("PACKAGE_ARCH", True)
> > +    machine_arch = d.getVar("MACHINE_ARCH", True)
> > +    if package_arch == machine_arch:
> > +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
> >  }
> > diff --git a/meta/classes/rootfs_rpm.bbclass
> > b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644
> > --- a/meta/classes/rootfs_rpm.bbclass
> > +++ b/meta/classes/rootfs_rpm.bbclass
> > @@ -218,7 +218,9 @@ python () {
> >              default_tune =
> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
> >              if default_tune:
> >                  localdata.setVar("DEFAULTTUNE", default_tune)
> > -            ml_package_archs += localdata.getVar("PACKAGE_ARCHS",
> True) or ""
> > +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
> localdata.getVar("MACHINE_ARCH", False))
> > +            package_archs = localdata.getVar("PACKAGE_ARCHS", True)
> or ""
> > +            ml_package_archs += " " + package_archs
> >              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
> >      bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs,
> d)  }
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Mark Hatle]

On 9/12/11 10:07 AM, Xu, Dongxiao wrote:
> Hi Mark,
> 
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, September 12, 2011 10:56 PM
>> To: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under
>> deploy/rpm
>>
>> On 9/12/11 3:34 AM, Dongxiao Xu wrote:
>>> Currently MACHINE_ARCH deploy folder is unique in multilib system,
>>> thus a lib32 version of rpm package will override a normal rpm package
>>> if its PACKAGE_ARCH is ${MACHINE_ARCH}.
>>>
>>> Define different deploy folder for multilib architectures to avoid the
>>> confliction.
>>
>> I'm not sure I understand here.  Within the deployment directory is a set of
>> directories for each RPM architecture.  Are you saying that we can get two
>> packages that have different contents but the same RPM architecture?
>>
> 
> Yes, for example the netbase recipe, which the PACKAGE_ARCH = MACHINE_ARCH.
> Both the normal version of netbase package and the lib32 version are named as
> "netbase-4.45-r1.qemux86_64.rpm" putting in tmp/deploy/rpm/qemux86-64 directory,
> so we need to differentiate them.

Wow, that is very broken.  I think part of the problem is that the arch is used
to signify not only ABI (and optimizations), but also machine type in this case.

What we really need is an additional architecture type that handles machine
specific packages for each multilib type.  I'm really not sure what they would
be called or how it would work though.

Anyone have suggestions for naming and processing of these?  (I'm almost tempted
to say "machine_lib")

--Mark

> Thanks,
> Dongxiao
> 
>> Can you give me an example of what is going wrong?
>>
>> --Mark
>>
>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>> ---
>>>  meta/classes/multilib.bbclass   |    5 +++++
>>>  meta/classes/rootfs_rpm.bbclass |    4 +++-
>>>  2 files changed, 8 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/meta/classes/multilib.bbclass
>>> b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644
>>> --- a/meta/classes/multilib.bbclass
>>> +++ b/meta/classes/multilib.bbclass
>>> @@ -77,4 +77,9 @@ python __anonymous () {
>>>      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
>>>      multilib_map_variable("PACKAGE_INSTALL", variant, d)
>>>      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
>>> +
>>> +    package_arch = d.getVar("PACKAGE_ARCH", True)
>>> +    machine_arch = d.getVar("MACHINE_ARCH", True)
>>> +    if package_arch == machine_arch:
>>> +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
>>>  }
>>> diff --git a/meta/classes/rootfs_rpm.bbclass
>>> b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644
>>> --- a/meta/classes/rootfs_rpm.bbclass
>>> +++ b/meta/classes/rootfs_rpm.bbclass
>>> @@ -218,7 +218,9 @@ python () {
>>>              default_tune =
>> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
>>>              if default_tune:
>>>                  localdata.setVar("DEFAULTTUNE", default_tune)
>>> -            ml_package_archs += localdata.getVar("PACKAGE_ARCHS",
>> True) or ""
>>> +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
>> localdata.getVar("MACHINE_ARCH", False))
>>> +            package_archs = localdata.getVar("PACKAGE_ARCHS", True)
>> or ""
>>> +            ml_package_archs += " " + package_archs
>>>              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
>> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
>>>      bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs,
>> d)  }
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Xu, Dongxiao]

Hi Mark,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Tuesday, September 13, 2011 1:23 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under
> deploy/rpm
> 
> On 9/12/11 10:07 AM, Xu, Dongxiao wrote:
> > Hi Mark,
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> >> Of Mark Hatle
> >> Sent: Monday, September 12, 2011 10:56 PM
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs
> >> under deploy/rpm
> >>
> >> On 9/12/11 3:34 AM, Dongxiao Xu wrote:
> >>> Currently MACHINE_ARCH deploy folder is unique in multilib system,
> >>> thus a lib32 version of rpm package will override a normal rpm
> >>> package if its PACKAGE_ARCH is ${MACHINE_ARCH}.
> >>>
> >>> Define different deploy folder for multilib architectures to avoid
> >>> the confliction.
> >>
> >> I'm not sure I understand here.  Within the deployment directory is a
> >> set of directories for each RPM architecture.  Are you saying that we
> >> can get two packages that have different contents but the same RPM
> architecture?
> >>
> >
> > Yes, for example the netbase recipe, which the PACKAGE_ARCH =
> MACHINE_ARCH.
> > Both the normal version of netbase package and the lib32 version are
> > named as "netbase-4.45-r1.qemux86_64.rpm" putting in
> > tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them.
> 
> Wow, that is very broken.  I think part of the problem is that the arch is used to
> signify not only ABI (and optimizations), but also machine type in this case.
> 
> What we really need is an additional architecture type that handles machine
> specific packages for each multilib type.  I'm really not sure what they would
> be called or how it would work though.
> 
> Anyone have suggestions for naming and processing of these?  (I'm almost
> tempted to say "machine_lib")

In the weekend I had a talk with Richard and he suggested on adding MLPREFIX to MACHINE_ARCH to differentiate them.
Otherwise user need to define a new value for MACHINE_virtclass-multilib-lib32?

Thanks,
Dongxiao

> 
> --Mark
> 
> > Thanks,
> > Dongxiao
> >
> >> Can you give me an example of what is going wrong?
> >>
> >> --Mark
> >>
> >>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> >>> ---
> >>>  meta/classes/multilib.bbclass   |    5 +++++
> >>>  meta/classes/rootfs_rpm.bbclass |    4 +++-
> >>>  2 files changed, 8 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/meta/classes/multilib.bbclass
> >>> b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644
> >>> --- a/meta/classes/multilib.bbclass
> >>> +++ b/meta/classes/multilib.bbclass
> >>> @@ -77,4 +77,9 @@ python __anonymous () {
> >>>      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
> >>>      multilib_map_variable("PACKAGE_INSTALL", variant, d)
> >>>      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
> >>> +
> >>> +    package_arch = d.getVar("PACKAGE_ARCH", True)
> >>> +    machine_arch = d.getVar("MACHINE_ARCH", True)
> >>> +    if package_arch == machine_arch:
> >>> +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
> >>>  }
> >>> diff --git a/meta/classes/rootfs_rpm.bbclass
> >>> b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644
> >>> --- a/meta/classes/rootfs_rpm.bbclass
> >>> +++ b/meta/classes/rootfs_rpm.bbclass
> >>> @@ -218,7 +218,9 @@ python () {
> >>>              default_tune =
> >> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
> >>>              if default_tune:
> >>>                  localdata.setVar("DEFAULTTUNE", default_tune)
> >>> -            ml_package_archs += localdata.getVar("PACKAGE_ARCHS",
> >> True) or ""
> >>> +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
> >> localdata.getVar("MACHINE_ARCH", False))
> >>> +            package_archs = localdata.getVar("PACKAGE_ARCHS",
> True)
> >> or ""
> >>> +            ml_package_archs += " " + package_archs
> >>>              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
> >> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
> >>>      bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs,
> >> d)  }
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Mark Hatle]

On 9/12/11 9:39 PM, Xu, Dongxiao wrote:
> Hi Mark,
> 
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Tuesday, September 13, 2011 1:23 AM
>> To: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under
>> deploy/rpm
>>
>> On 9/12/11 10:07 AM, Xu, Dongxiao wrote:
>>> Hi Mark,
>>>
>>>> -----Original Message-----
>>>> From: openembedded-core-bounces@lists.openembedded.org
>>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
>>>> Of Mark Hatle
>>>> Sent: Monday, September 12, 2011 10:56 PM
>>>> To: openembedded-core@lists.openembedded.org
>>>> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs
>>>> under deploy/rpm
>>>>
>>>> On 9/12/11 3:34 AM, Dongxiao Xu wrote:
>>>>> Currently MACHINE_ARCH deploy folder is unique in multilib system,
>>>>> thus a lib32 version of rpm package will override a normal rpm
>>>>> package if its PACKAGE_ARCH is ${MACHINE_ARCH}.
>>>>>
>>>>> Define different deploy folder for multilib architectures to avoid
>>>>> the confliction.
>>>>
>>>> I'm not sure I understand here.  Within the deployment directory is a
>>>> set of directories for each RPM architecture.  Are you saying that we
>>>> can get two packages that have different contents but the same RPM
>> architecture?
>>>>
>>>
>>> Yes, for example the netbase recipe, which the PACKAGE_ARCH =
>> MACHINE_ARCH.
>>> Both the normal version of netbase package and the lib32 version are
>>> named as "netbase-4.45-r1.qemux86_64.rpm" putting in
>>> tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them.
>>
>> Wow, that is very broken.  I think part of the problem is that the arch is used to
>> signify not only ABI (and optimizations), but also machine type in this case.
>>
>> What we really need is an additional architecture type that handles machine
>> specific packages for each multilib type.  I'm really not sure what they would
>> be called or how it would work though.
>>
>> Anyone have suggestions for naming and processing of these?  (I'm almost
>> tempted to say "machine_lib")
> 
> In the weekend I had a talk with Richard and he suggested on adding MLPREFIX to MACHINE_ARCH to differentiate them.
> Otherwise user need to define a new value for MACHINE_virtclass-multilib-lib32?

I can't think of a better solution for this right now.  Note, that if the
MLPREFIX is added to the MACHINE_ARCH, a corresponding change to Zypper will be
needed as well.

--Mark

> Thanks,
> Dongxiao
> 
>>
>> --Mark
>>
>>> Thanks,
>>> Dongxiao
>>>
>>>> Can you give me an example of what is going wrong?
>>>>
>>>> --Mark
>>>>
>>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>>>> ---
>>>>>  meta/classes/multilib.bbclass   |    5 +++++
>>>>>  meta/classes/rootfs_rpm.bbclass |    4 +++-
>>>>>  2 files changed, 8 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/meta/classes/multilib.bbclass
>>>>> b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644
>>>>> --- a/meta/classes/multilib.bbclass
>>>>> +++ b/meta/classes/multilib.bbclass
>>>>> @@ -77,4 +77,9 @@ python __anonymous () {
>>>>>      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
>>>>>      multilib_map_variable("PACKAGE_INSTALL", variant, d)
>>>>>      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
>>>>> +
>>>>> +    package_arch = d.getVar("PACKAGE_ARCH", True)
>>>>> +    machine_arch = d.getVar("MACHINE_ARCH", True)
>>>>> +    if package_arch == machine_arch:
>>>>> +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
>>>>>  }
>>>>> diff --git a/meta/classes/rootfs_rpm.bbclass
>>>>> b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644
>>>>> --- a/meta/classes/rootfs_rpm.bbclass
>>>>> +++ b/meta/classes/rootfs_rpm.bbclass
>>>>> @@ -218,7 +218,9 @@ python () {
>>>>>              default_tune =
>>>> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
>>>>>              if default_tune:
>>>>>                  localdata.setVar("DEFAULTTUNE", default_tune)
>>>>> -            ml_package_archs += localdata.getVar("PACKAGE_ARCHS",
>>>> True) or ""
>>>>> +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
>>>> localdata.getVar("MACHINE_ARCH", False))
>>>>> +            package_archs = localdata.getVar("PACKAGE_ARCHS",
>> True)
>>>> or ""
>>>>> +            ml_package_archs += " " + package_archs
>>>>>              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
>>>> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
>>>>>      bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs,
>>>> d)  }
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Xu, Dongxiao]

Hi Mark,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Tuesday, September 13, 2011 11:24 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under
> deploy/rpm
> 
> On 9/12/11 9:39 PM, Xu, Dongxiao wrote:
> > Hi Mark,
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> >> Of Mark Hatle
> >> Sent: Tuesday, September 13, 2011 1:23 AM
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs
> >> under deploy/rpm
> >>
> >> On 9/12/11 10:07 AM, Xu, Dongxiao wrote:
> >>> Hi Mark,
> >>>
> >>>> -----Original Message-----
> >>>> From: openembedded-core-bounces@lists.openembedded.org
> >>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On
> Behalf
> >>>> Of Mark Hatle
> >>>> Sent: Monday, September 12, 2011 10:56 PM
> >>>> To: openembedded-core@lists.openembedded.org
> >>>> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for
> >>>> archs under deploy/rpm
> >>>>
> >>>> On 9/12/11 3:34 AM, Dongxiao Xu wrote:
> >>>>> Currently MACHINE_ARCH deploy folder is unique in multilib system,
> >>>>> thus a lib32 version of rpm package will override a normal rpm
> >>>>> package if its PACKAGE_ARCH is ${MACHINE_ARCH}.
> >>>>>
> >>>>> Define different deploy folder for multilib architectures to avoid
> >>>>> the confliction.
> >>>>
> >>>> I'm not sure I understand here.  Within the deployment directory is
> >>>> a set of directories for each RPM architecture.  Are you saying
> >>>> that we can get two packages that have different contents but the
> >>>> same RPM
> >> architecture?
> >>>>
> >>>
> >>> Yes, for example the netbase recipe, which the PACKAGE_ARCH =
> >> MACHINE_ARCH.
> >>> Both the normal version of netbase package and the lib32 version are
> >>> named as "netbase-4.45-r1.qemux86_64.rpm" putting in
> >>> tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them.
> >>
> >> Wow, that is very broken.  I think part of the problem is that the
> >> arch is used to signify not only ABI (and optimizations), but also machine
> type in this case.
> >>
> >> What we really need is an additional architecture type that handles
> >> machine specific packages for each multilib type.  I'm really not
> >> sure what they would be called or how it would work though.
> >>
> >> Anyone have suggestions for naming and processing of these?  (I'm
> >> almost tempted to say "machine_lib")
> >
> > In the weekend I had a talk with Richard and he suggested on adding
> MLPREFIX to MACHINE_ARCH to differentiate them.
> > Otherwise user need to define a new value for
> MACHINE_virtclass-multilib-lib32?
> 
> I can't think of a better solution for this right now.  Note, that if the MLPREFIX
> is added to the MACHINE_ARCH, a corresponding change to Zypper will be
> needed as well.

I tried this approach by defining 'MACHINE_virtclass-multilib-lib32="qemux86"' in local.conf, and it works. Therefore we will have qemux86, qemux86-64, x86, x86-64, and all architectures under tmp/deploy/rpm folder. 

Does zypper work with this approach?

Thanks,
Dongxiao

> 
> --Mark
> 
> > Thanks,
> > Dongxiao
> >
> >>
> >> --Mark
> >>
> >>> Thanks,
> >>> Dongxiao
> >>>
> >>>> Can you give me an example of what is going wrong?
> >>>>
> >>>> --Mark
> >>>>
> >>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> >>>>> ---
> >>>>>  meta/classes/multilib.bbclass   |    5 +++++
> >>>>>  meta/classes/rootfs_rpm.bbclass |    4 +++-
> >>>>>  2 files changed, 8 insertions(+), 1 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/classes/multilib.bbclass
> >>>>> b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644
> >>>>> --- a/meta/classes/multilib.bbclass
> >>>>> +++ b/meta/classes/multilib.bbclass
> >>>>> @@ -77,4 +77,9 @@ python __anonymous () {
> >>>>>      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
> >>>>>      multilib_map_variable("PACKAGE_INSTALL", variant, d)
> >>>>>      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
> >>>>> +
> >>>>> +    package_arch = d.getVar("PACKAGE_ARCH", True)
> >>>>> +    machine_arch = d.getVar("MACHINE_ARCH", True)
> >>>>> +    if package_arch == machine_arch:
> >>>>> +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
> >>>>>  }
> >>>>> diff --git a/meta/classes/rootfs_rpm.bbclass
> >>>>> b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644
> >>>>> --- a/meta/classes/rootfs_rpm.bbclass
> >>>>> +++ b/meta/classes/rootfs_rpm.bbclass
> >>>>> @@ -218,7 +218,9 @@ python () {
> >>>>>              default_tune =
> >>>> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1],
> >>>> False)
> >>>>>              if default_tune:
> >>>>>                  localdata.setVar("DEFAULTTUNE", default_tune)
> >>>>> -            ml_package_archs +=
> localdata.getVar("PACKAGE_ARCHS",
> >>>> True) or ""
> >>>>> +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
> >>>> localdata.getVar("MACHINE_ARCH", False))
> >>>>> +            package_archs = localdata.getVar("PACKAGE_ARCHS",
> >> True)
> >>>> or ""
> >>>>> +            ml_package_archs += " " + package_archs
> >>>>>              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
> >>>> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
> >>>>>      bb.data.setVar('MULTILIB_PACKAGE_ARCHS',
> ml_package_archs,
> >>>> d)  }
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Openembedded-core mailing list
> >>>> Openembedded-core@lists.openembedded.org
> >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-co
> >>>> re
> >>>
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-cor
> >>> e
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

[Mark Hatle]

On 9/13/11 9:56 PM, Xu, Dongxiao wrote:
> Hi Mark,
> 
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Tuesday, September 13, 2011 11:24 PM
>> To: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under
>> deploy/rpm
>>
>> On 9/12/11 9:39 PM, Xu, Dongxiao wrote:
>>> Hi Mark,
>>>
>>>> -----Original Message-----
>>>> From: openembedded-core-bounces@lists.openembedded.org
>>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
>>>> Of Mark Hatle
>>>> Sent: Tuesday, September 13, 2011 1:23 AM
>>>> To: openembedded-core@lists.openembedded.org
>>>> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs
>>>> under deploy/rpm
>>>>
>>>> On 9/12/11 10:07 AM, Xu, Dongxiao wrote:
>>>>> Hi Mark,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: openembedded-core-bounces@lists.openembedded.org
>>>>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On
>> Behalf
>>>>>> Of Mark Hatle
>>>>>> Sent: Monday, September 12, 2011 10:56 PM
>>>>>> To: openembedded-core@lists.openembedded.org
>>>>>> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for
>>>>>> archs under deploy/rpm
>>>>>>
>>>>>> On 9/12/11 3:34 AM, Dongxiao Xu wrote:
>>>>>>> Currently MACHINE_ARCH deploy folder is unique in multilib system,
>>>>>>> thus a lib32 version of rpm package will override a normal rpm
>>>>>>> package if its PACKAGE_ARCH is ${MACHINE_ARCH}.
>>>>>>>
>>>>>>> Define different deploy folder for multilib architectures to avoid
>>>>>>> the confliction.
>>>>>>
>>>>>> I'm not sure I understand here.  Within the deployment directory is
>>>>>> a set of directories for each RPM architecture.  Are you saying
>>>>>> that we can get two packages that have different contents but the
>>>>>> same RPM
>>>> architecture?
>>>>>>
>>>>>
>>>>> Yes, for example the netbase recipe, which the PACKAGE_ARCH =
>>>> MACHINE_ARCH.
>>>>> Both the normal version of netbase package and the lib32 version are
>>>>> named as "netbase-4.45-r1.qemux86_64.rpm" putting in
>>>>> tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them.
>>>>
>>>> Wow, that is very broken.  I think part of the problem is that the
>>>> arch is used to signify not only ABI (and optimizations), but also machine
>> type in this case.
>>>>
>>>> What we really need is an additional architecture type that handles
>>>> machine specific packages for each multilib type.  I'm really not
>>>> sure what they would be called or how it would work though.
>>>>
>>>> Anyone have suggestions for naming and processing of these?  (I'm
>>>> almost tempted to say "machine_lib")
>>>
>>> In the weekend I had a talk with Richard and he suggested on adding
>> MLPREFIX to MACHINE_ARCH to differentiate them.
>>> Otherwise user need to define a new value for
>> MACHINE_virtclass-multilib-lib32?
>>
>> I can't think of a better solution for this right now.  Note, that if the MLPREFIX
>> is added to the MACHINE_ARCH, a corresponding change to Zypper will be
>> needed as well.
> 
> I tried this approach by defining 'MACHINE_virtclass-multilib-lib32="qemux86"' in local.conf, and it works. Therefore we will have qemux86, qemux86-64, x86, x86-64, and all architectures under tmp/deploy/rpm folder. 
> 
> Does zypper work with this approach?

This should work, we just need to ensure that zypper/libzypp are paying
attention to the MACHINE... type(s) as well.  There is a small chunk of code
within the libzypp recipe that generates a table of available/compatible
architectures.  This is what will need to be updated.

(I do think the MACHINE_virtclass change you made is likely the best approach
right now.)

--Mark

> Thanks,
> Dongxiao
> 
>>
>> --Mark
>>
>>> Thanks,
>>> Dongxiao
>>>
>>>>
>>>> --Mark
>>>>
>>>>> Thanks,
>>>>> Dongxiao
>>>>>
>>>>>> Can you give me an example of what is going wrong?
>>>>>>
>>>>>> --Mark
>>>>>>
>>>>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>>>>>> ---
>>>>>>>  meta/classes/multilib.bbclass   |    5 +++++
>>>>>>>  meta/classes/rootfs_rpm.bbclass |    4 +++-
>>>>>>>  2 files changed, 8 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>>> diff --git a/meta/classes/multilib.bbclass
>>>>>>> b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644
>>>>>>> --- a/meta/classes/multilib.bbclass
>>>>>>> +++ b/meta/classes/multilib.bbclass
>>>>>>> @@ -77,4 +77,9 @@ python __anonymous () {
>>>>>>>      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
>>>>>>>      multilib_map_variable("PACKAGE_INSTALL", variant, d)
>>>>>>>      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
>>>>>>> +
>>>>>>> +    package_arch = d.getVar("PACKAGE_ARCH", True)
>>>>>>> +    machine_arch = d.getVar("MACHINE_ARCH", True)
>>>>>>> +    if package_arch == machine_arch:
>>>>>>> +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
>>>>>>>  }
>>>>>>> diff --git a/meta/classes/rootfs_rpm.bbclass
>>>>>>> b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644
>>>>>>> --- a/meta/classes/rootfs_rpm.bbclass
>>>>>>> +++ b/meta/classes/rootfs_rpm.bbclass
>>>>>>> @@ -218,7 +218,9 @@ python () {
>>>>>>>              default_tune =
>>>>>> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1],
>>>>>> False)
>>>>>>>              if default_tune:
>>>>>>>                  localdata.setVar("DEFAULTTUNE", default_tune)
>>>>>>> -            ml_package_archs +=
>> localdata.getVar("PACKAGE_ARCHS",
>>>>>> True) or ""
>>>>>>> +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
>>>>>> localdata.getVar("MACHINE_ARCH", False))
>>>>>>> +            package_archs = localdata.getVar("PACKAGE_ARCHS",
>>>> True)
>>>>>> or ""
>>>>>>> +            ml_package_archs += " " + package_archs
>>>>>>>              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
>>>>>> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
>>>>>>>      bb.data.setVar('MULTILIB_PACKAGE_ARCHS',
>> ml_package_archs,
>>>>>> d)  }
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openembedded-core mailing list
>>>>>> Openembedded-core@lists.openembedded.org
>>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-co
>>>>>> re
>>>>>
>>>>> _______________________________________________
>>>>> Openembedded-core mailing list
>>>>> Openembedded-core@lists.openembedded.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-cor
>>>>> e
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[PATCH 3/3] multilib: install MULTILIB_PACKAGE_INSTALL

[Dongxiao Xu]

If user set MULTILIB_PACKAGE_INSTALL, we need to install those multitlib
packages into the final image.

Also fix the logic in handling multilib prefix. For certain case like a
normal image contains several multilib libraries, the image recipe isn't
extended with MLPREFIX, therefore we need to enumerate the possible
multilib prefixes and compare them with package prefixes.

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 meta/classes/package_rpm.bbclass |   42 +++++++++++++++++++++++++------------
 meta/classes/rootfs_rpm.bbclass  |    4 +++
 2 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index ea0a079..5e5fb6c 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -166,7 +166,7 @@ package_install_internal_rpm () {
 	local platform="${INSTALL_PLATFORM_RPM}"
 	local platform_extra="${INSTALL_PLATFORM_EXTRA_RPM}"
 	local confbase="${INSTALL_CONFBASE_RPM}"
-	local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM}"
+	local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM} ${INSTALL_PACKAGES_MULTILIB_RPM}"
 	local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_RPM}"
 	local package_linguas="${INSTALL_PACKAGES_LINGUAS_RPM}"
 	local providename="${INSTALL_PROVIDENAME_RPM}"
@@ -210,10 +210,15 @@ package_install_internal_rpm () {
 				echo "Processing $pkg..."
 
 				archvar=base_archs
-				ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
-				if [ "${ml_pkg}" != "${pkg}" ]; then
-					archvar=ml_archs
-				fi
+				ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+				ml_pkg=$pkg
+				for i in ${MULTILIB_PREFIX_LIST} ; do
+					if [ ${ml_prefix} == ${i} ]; then
+						ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
+						archvar=ml_archs
+						break
+					fi
+				done
 
 				pkg_name=$(resolve_package_rpm ${confbase}-${archvar}.conf ${ml_pkg})
 				if [ -z "$pkg_name" ]; then
@@ -224,16 +229,20 @@ package_install_internal_rpm () {
 			done
 		fi
 	fi
-
 	if [ ! -z "${package_to_install}" ]; then
 		for pkg in ${package_to_install} ; do
 			echo "Processing $pkg..."
 
 			archvar=base_archs
-			ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
-			if [ "${ml_pkg}" != "${pkg}" ]; then
-				archvar=ml_archs
-			fi
+			ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+			ml_pkg=$pkg
+			for i in ${MULTILIB_PREFIX_LIST} ; do
+				if [ ${ml_prefix} == ${i} ]; then
+					ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
+					archvar=ml_archs
+					break
+				fi
+			done
 
 			pkg_name=$(resolve_package_rpm ${confbase}-${archvar}.conf ${ml_pkg})
 			if [ -z "$pkg_name" ]; then
@@ -258,10 +267,15 @@ package_install_internal_rpm () {
 		for pkg in ${package_attemptonly} ; do
 			echo "Processing $pkg..."
 			archvar=base_archs
-			ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
-			if [ "${ml_pkg}" != "${pkg}" ]; then
-				archvar=ml_archs
-			fi
+			ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+			ml_pkg=$pkg
+			for i in ${MULTILIB_PREFIX_LIST} ; do
+				if [ ${ml_prefix} == ${i} ]; then
+					ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
+					archvar=ml_archs
+					break
+				fi
+			done
 
 			pkg_name=$(resolve_package_rpm ${confbase}-${archvar}.conf ${ml_pkg})
 			if [ -z "$pkg_name" ]; then
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 7936d77..5ac6bca 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -58,6 +58,7 @@ fakeroot rootfs_rpm_do_rootfs () {
 	export INSTALL_PLATFORM_RPM="${TARGET_ARCH}"
 	export INSTALL_CONFBASE_RPM="${RPMCONF_TARGET_BASE}"
 	export INSTALL_PACKAGES_NORMAL_RPM="${PACKAGE_INSTALL}"
+	export INSTALL_PACKAGES_MULTILIB_RPM="${MULTILIB_PACKAGE_INSTALL}"
 	export INSTALL_PACKAGES_ATTEMPTONLY_RPM="${PACKAGE_INSTALL_ATTEMPTONLY}"
 	export INSTALL_PACKAGES_LINGUAS_RPM="${LINGUAS_INSTALL}"
 	export INSTALL_PROVIDENAME_RPM=""
@@ -210,6 +211,7 @@ python () {
         bb.data.setVar('RPM_POSTPROCESS_COMMANDS', '', d)
 
     ml_package_archs = ""
+    ml_prefix_list = ""
     multilibs = d.getVar('MULTILIBS', True) or ""
     for ext in multilibs.split():
         eext = ext.split(':')
@@ -221,6 +223,8 @@ python () {
             localdata.setVar("MACHINE_ARCH", eext[1] + "_" + localdata.getVar("MACHINE_ARCH", False))
             package_archs = localdata.getVar("PACKAGE_ARCHS", True) or ""
             ml_package_archs += " " + package_archs
+            ml_prefix_list += " " + eext[1]
             #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1], localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
     bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
+    bb.data.setVar('MULTILIB_PREFIX_LIST', ml_prefix_list, d)
 }
-- 
1.7.1