[OE-core] [PATCH 1/3] package_rpm: add architecture info in rpm spec file
Xu, Dongxiao
dongxiao.xu at intel.com
Tue Sep 13 15:41:56 UTC 2011
Hi Mark,
> -----Original Message-----
> From: Mark Hatle [mailto:mark.hatle at 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 at lists.openembedded.org
> >> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf
> >> Of Mark Hatle
> >> Sent: Monday, September 12, 2011 10:52 PM
> >> To: openembedded-core at 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 at 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 at lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
More information about the Openembedded-core
mailing list