Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file
Date: Tue, 13 Sep 2011 10:29:11 -0500	[thread overview]
Message-ID: <4E6F76C7.6050606@windriver.com> (raw)
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A12D754AFF1@shsmsx501.ccr.corp.intel.com>

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




  reply	other threads:[~2011-09-13 15:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-12  8:33 [PATCH 0/3][RFC] rpm: multilib related fixes Dongxiao Xu
2011-09-12  8:33 ` [PATCH 1/3] package_rpm: add architecture info in rpm spec file Dongxiao Xu
2011-09-12 14:51   ` Mark Hatle
2011-09-13  2:24     ` Xu, Dongxiao
2011-09-13 15:29       ` Mark Hatle [this message]
2011-09-13 15:41         ` Xu, Dongxiao
2011-09-13 15:58           ` Mark Hatle
2011-09-14  1:03             ` Xu, Dongxiao
2011-09-14 14:33               ` Mark Hatle
2011-09-12  8:34 ` [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm Dongxiao Xu
2011-09-12 14:55   ` Mark Hatle
2011-09-12 15:07     ` Xu, Dongxiao
2011-09-12 17:22       ` Mark Hatle
2011-09-13  2:39         ` Xu, Dongxiao
2011-09-13 15:24           ` Mark Hatle
2011-09-14  2:56             ` Xu, Dongxiao
2011-09-14 14:34               ` Mark Hatle
2011-09-12  8:34 ` [PATCH 3/3] multilib: install MULTILIB_PACKAGE_INSTALL Dongxiao Xu
  -- strict thread matches above, loose matches on Subject: below --
2011-09-14  6:08 [PATCH 0/3][RFC v2] rpm: multilib related fixes Dongxiao Xu
2011-09-14  6:08 ` [PATCH 1/3] package_rpm: add architecture info in rpm spec file Dongxiao Xu
2011-09-14 14:37   ` Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E6F76C7.6050606@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=dongxiao.xu@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox