add variable INSTALL_ALL to install all packages in recipes
cover add variable INSTALL_ALL to install all packages in recipes
Test Steps:
Install busybox and lib32-python3 to core-image-minimal, and also install all available packages of recipes busybox and python3.
1. vim local.conf
...
MACHINE ?= "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"IMAGE_INSTALL_append = " busybox lib32-python3"INSTALL_ALL_busybox ?= "1"
INSTALL_ALL_lib32-python3 ?= "1"
...
2. Build core-image-minimal
$ bitbake core-image-minimal
3. Check installed_pkgs.txt, all available packages of recipes busybox and lib32-python3 have been installed.
...
$ cat tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/installed_pkgs.txt ... busybox core2-64 busybox-hwclock core2-64 busybox-syslog core2-64 busybox-udhcpc core2-64 busybox-udhcpd core2-64 ...
4. Edit local.conf to assign INSTALL_ALL_busybox ?= "0"
5. build core-image-minimal
6. Check installed_pkgs.txt, busybox-udhcpd not installed
...
$ cat tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/installed_pkgs.txt ... busybox core2-64 busybox-hwclock core2-64 busybox-syslog core2-64 busybox-udhcpc core2-64 ...
//Hongxu
The following changes since commit bfe7d3032a61a20010b5b758be07581e1bf01cba:
gstreamer1.0-omx: use mulitple SCMs to fetch submodules (2014-12-31 17:04:52 +0000)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib hongxu/install-all
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/install-all
Hongxu Jia (4):
scripts/oe-pkgdata-util: support rprovides for lookup-recipe scripts/oe-pkgdata-util: add ability to list all produced packages
from a recipe
python3: avoid debian renaming for libpython3 manifest.py/image.bbclass: add var-INSTALL_ALL to install all packages
of a recipes.
meta/classes/image.bbclass | 19 ++++- meta/lib/oe/manifest.py | 56 +++++++++++++- meta/recipes-devtools/python/python3_3.3.3.bb | 2 + scripts/oe-pkgdata-util | 101 +++++++++++++++++++++++++- 4 files changed, 174 insertions(+), 4 deletions(-)
Signature · 1 line
1.9.1
PATCH 1/4 scripts/oe-pkgdata-util: support rprovides for lookup-recipe
If failed to invoke lookup-recipe while pkg not generated but provided by others, such as python3, it is provided by python3-core
...
$ bitbake python3 $ oe-pkgdata-util -d lookup-recipe tmp/sysroots/qemux86/pkgdata/ "python3" ERROR: the following packages could not be found: python3 ...
In this situation, we search the pkg's rprovides (if available) to replace.
[YOCTO #5264]
--- scripts/oe-pkgdata-util | 54 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+)
scripts/oe-pkgdata-util +54 -0
@@ -27,6 +27,7 @@ import fnmatch import re import optparse from collections import defaultdict +import codecs def glob(args, usage, debug=False): if len(args) < 3:
@@ -234,6 +235,19 @@ def lookup_recipe(args, usage, debug=False): print('ERROR: Unable to find pkgdata directory %s' % pkgdata_dir) sys.exit(1) + # If the pkg not generated, search the rprovides to replace + rprovides = collect_rprovides(pkgdata_dir) + for pkg in pkgs[:]: + pkgfile = os.path.join(pkgdata_dir, 'runtime', pkg) + if not os.path.exists(pkgfile): + for newpkg, oldpkg in rprovides.items(): + if oldpkg == pkg: + if debug: + print('%s rprovides %s' % (newpkg, pkg)) + pkgs.remove(pkg) + pkgs.append(newpkg) + break + mappings = defaultdict(list) for pkg in pkgs: pkgfile = os.path.join(pkgdata_dir, 'runtime-reverse', pkg)
@@ -254,6 +268,46 @@ def lookup_recipe(args, usage, debug=False): items.extend(mappings.get(pkg, [])) print '\n'.join(items) +def collect_rprovides(pkgdata_dir): + def read_pkgdatafile(fn): + pkgdata = {} + def decode(str): + c = codecs.getdecoder("string_escape") + return c(str)[0] + + if os.access(fn, os.R_OK): + import re + f = open(fn, 'r') + lines = f.readlines() + f.close() + r = re.compile("([^:]+):\s*(.*)") + for l in lines: + m = r.match(l) + if m: + pkgdata[m.group(1)] = decode(m.group(2)) + return pkgdata + + rprovides_dict = dict() + if os.path.exists(pkgdata_dir): + for root, dirs, files in os.walk("%s/runtime" % pkgdata_dir): + for pkgname in files: + pkgdatafile = "%s/%s" % (root, pkgname) + if not os.access("%s.packaged" % pkgdatafile, os.R_OK): + continue + + try: + sdata = read_pkgdatafile(pkgdatafile) + rprovides = sdata.get('RPROVIDES_%s' % pkgname) + if rprovides: + rprovides_dict[pkgname] = rprovides + + except Exception as e: + print("ERROR:%s: Failed to read pkgdata file %s: %s: %s" % + (pkgname, pkgdatafile, e.__class__, str(e))) + sys.exit(1) + + return rprovides_dict + def find_path(args, usage, debug=False): if len(args) < 2: usage()
Signature · 1 line
1.9.1
PATCH 2/4 scripts/oe-pkgdata-util: add ability to list all produced packages from a recipe
In reply to Hongxu JiaAdd a "list-packages" command to list all produced packages by a particular recipe.
[YOCTO #5264]
--- scripts/oe-pkgdata-util | 47 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 46 insertions(+), 1 deletion(-)
scripts/oe-pkgdata-util +46 -1
@@ -28,6 +28,7 @@ import re import optparse from collections import defaultdict import codecs +import errno def glob(args, usage, debug=False): if len(args) < 3:
@@ -308,6 +309,46 @@ def collect_rprovides(pkgdata_dir): return rprovides_dict +def list_packages(args, usage, debug=False): + if len(args) < 2: + usage() + sys.exit(1) + + pkgdata_dir = args[0] + if not os.path.exists(pkgdata_dir): + print('ERROR: Unable to find pkgdata directory %s' % pkgdata_dir) + sys.exit(1) + + if len(args[1].split()) != 1: + print('ERROR: Only one recipe name is acceptable') + sys.exit(1) + + recipe = args[1] + packages = "" + try: + with open(os.path.join(pkgdata_dir, recipe)) as f: + for line in f.readlines(): + if line.startswith('PACKAGES: '): + packages = line.split(': ', 1)[1].split() + break + except IOError as e: + if e.errno == errno.ENOENT: + print('ERROR: The recipe %s does not exist' % recipe) + sys.exit(1) + else: + raise + + # Filter out packages that not generated + for pkg in packages[:]: + flag_packaged = "%s/runtime/%s.packaged" % (pkgdata_dir, pkg) + if not os.access(flag_packaged, os.R_OK): + if debug: + print("%s not produced by %s" % (pkg, recipe)) + packages.remove(pkg) + + print '\n'.join(packages) + + def find_path(args, usage, debug=False): if len(args) < 2: usage()
@@ -354,7 +395,9 @@ Available commands: find the package providing the specified path (wildcards * ? allowed) read-value <pkgdatadir> <value-name> "<pkgs>" read the named value from the pkgdata files for the specified - packages''') + packages + list-packages <pkgdatadir> "<recipe>" + list all packages produced by the particular recipe''') parser.add_option("-d", "--debug", help = "Enable debug output",
@@ -377,6 +420,8 @@ Available commands: find_path(args[1:], parser.print_help, options.debug) elif args[0] == "read-value": read_value(args[1:], parser.print_help, options.debug) + elif args[0] == "list-packages": + list_packages(args[1:], parser.print_help, options.debug) else: parser.print_help() sys.exit(1)
Signature · 1 line
1.9.1
PATCH 3/4 python3: avoid debian renaming for libpython3
In reply to Hongxu JiaWhen Debian-renaming, 'libpython3' was incorrectly converted to 'libpython3.3m1.0', it caused install 'libpython3' failed. (IMAGE_INSTALL_append = " python3", INSTALL_ALL_python3 = "1")
...
ERROR: libpython3 not found in the base feeds (qemux86 i586 x86 noarch any all). libpython3.3m1.0-3.3.3-r0.0@i586
...
We assign DEBIAN_NOAUTONAME for 'libpython3' to avoid debian renaming.
The same to 'libpython3-staticdev'.
[YOCTO #5264]
--- meta/recipes-devtools/python/python3_3.3.3.bb | 2 ++ 1 file changed, 2 insertions(+)
meta/recipes-devtools/python/python3_3.3.3.bb +2 -0
@@ -204,6 +204,8 @@ FILES_${PN}-pyvenv += "${bindir}/pyvenv-${PYTHON_MAJMIN} ${bindir}/pyvenv" PACKAGES =+ "libpython3 libpython3-staticdev" FILES_libpython3 = "${libdir}/libpython*.so.*" FILES_libpython3-staticdev += "${libdir}/python${PYTHON_MAJMIN}/config-${PYTHON_BINABI}/libpython${PYTHON_BINABI}.a" +DEBIAN_NOAUTONAME_libpython3 = "1" +DEBIAN_NOAUTONAME_libpython3-staticdev = "1" # catch debug extensions (isn't that already in python-core-dbg?) FILES_${PN}-dbg += "${libdir}/python${PYTHON_MAJMIN}/lib-dynload/.debug"
Signature · 1 line
1.9.1
PATCH 4/4 manifest.py/image.bbclass: add var-INSTALL_ALL to install all packages of a recipes.
In reply to Hongxu JiaAdd variable INSTALL_ALL to install all available packages of a recipe, the recipe comes from the package listed in PACKAGE_INSTALL (IMAGE_INSTALL also)
Here is the design:
1) According to the packages listed in PACKAGE_INSTALL, figure out recipes which produced them by invoking script oe-pkgdata-util;
2) Go on invoking script oe-pkgdata-util to list all available packages in these recipes except *-(doc|dbg|dev|staticdev|locale|ptest), and use them to replace packages in PACKAGE_INSTALL;
3) Packages installation at do_rootfs time as normal;
4) INSTALL_ALL is a global switch for all packages listed in PACKAGE_INSTALL, you also could assign INSTALL_ALL_pkgname ?= "1" for the particular package in PACKAGE_INSTALL;
[YOCTO #5264]
--- meta/classes/image.bbclass | 19 +++++++++++++++- meta/lib/oe/manifest.py | 56 ++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 72 insertions(+), 3 deletions(-)
meta/classes/image.bbclass +18 -1
@@ -54,6 +54,16 @@ def check_image_features(d): if feature not in valid_features: bb.fatal("'%s' in IMAGE_FEATURES is not a valid image feature. Valid features: %s" % (feature, ' '.join(valid_features))) +# Assign INSTALL_ALL ?= "1" means: +# 1) According to the packages listed in PACKAGE_INSTALL, figure out recipes +# which produced them by invoking script oe-pkgdata-util; +# 2) Go on invoking script oe-pkgdata-util to list all available packages in +# these recipes except *-(doc|dbg|dev|staticdev|locale|ptest), and use them +# to replace packages in PACKAGE_INSTALL; +# 3) INSTALL_ALL is a global switch for all packages listed in PACKAGE_INSTALL, +# you also could assign INSTALL_ALL_pkgname ?= "1" for the particular +# package in PACKAGE_INSTALL. +INSTALL_ALL ?= "0" IMAGE_INSTALL ?= "" IMAGE_INSTALL[type] = "list" export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} ${FEATURE_INSTALL}"
@@ -95,9 +105,16 @@ def rootfs_variables(d): 'SDK_OUTPUT','SDKPATHNATIVE','SDKTARGETSYSROOT','SDK_DIR','SDK_VENDOR','SDKIMAGE_INSTALL_COMPLEMENTARY','SDK_PACKAGE_ARCHS','SDK_OUTPUT','SDKTARGETSYSROOT','MULTILIBRE_ALLOW_REP', 'MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS','PACKAGE_ARCHS', 'PACKAGE_CLASSES','TARGET_VENDOR','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','BUILDNAME','USE_DEVFS', - 'STAGING_KERNEL_DIR','COMPRESSIONTYPES'] + 'STAGING_KERNEL_DIR','COMPRESSIONTYPES', 'INSTALL_ALL'] variables.extend(command_variables(d)) variables.extend(variable_depends(d)) + + for pkg in (d.getVar('PACKAGE_INSTALL', True) or '').split(): + installall_var = 'INSTALL_ALL_%s' % pkg + installall_val = d.getVar(installall_var, True) + if installall_val and installall_var not in variables: + variables.append(installall_var) + return " ".join(variables) do_rootfs[vardeps] += "${@rootfs_variables(d)}"
meta/lib/oe/manifest.py +54 -2
76 lines not on this page · raw message
Signature · 1 line
1.9.1
This tells me what the change does. What it doesn't say is why we need this?
Its a fairly invasive set of changes but I don't see the usecase...
Cheers,
Richard
Quoted 4 lines · Richard Purdie
This tells me what the change does. What it doesn't say is why we need this?
Its a fairly invasive set of changes but I don't see the usecase...
Hi Richard,
I am sorry not to say it clearly,
1) We have been asked many times on how to install all the PACKAGES of a recipe, we can only list them one by one in the RDPENDS (or IMAGE_INSTALL and so on) currently, especially like dynamic generated packages (perl-modules, kernel-modules) which depends on many other packages, it is not easy to remember these package names for customer. It is helpful for user who does not take care the details that how many packages generated in a recipe, just want to directly install all of
them.
2) Providing a mechanism to install all the PACKAGES of a recipe is helpful to test all generated packages of a recipe could work, such as the
defect
of '[PATCH 3/4]' was found by installing all packages of python3.
3) The fix is based on the usage of IMAGE_INSTALL, so it doesn't affect the users who do not want to use this feature (We disable it by default).
//Hongxu
Quoted 4 lines
Cheers,
Richard
Quoted 21 lines · Hongxu Jia
Quoted 5 lines · Richard Purdie
This tells me what the change does. What it doesn't say is why we need this?
Its a fairly invasive set of changes but I don't see the usecase...
Hi Richard,
I am sorry not to say it clearly,
1) We have been asked many times on how to install all the PACKAGES of a recipe, we can only list them one by one in the RDPENDS (or
IMAGE_INSTALLand so on) currently, especially like dynamic generated packages (perl-modules, kernel-modules) which depends on many other packages, it is not easy to remember these package names for customer. It is helpful for user who does not take care the details that how many packages generated in a recipe, just want to directly install all of
them.
Quoted 6 lines
2) Providing a mechanism to install all the PACKAGES of a recipe is helpful to test all generated packages of a recipe could work, such as the defect of '[PATCH 3/4]' was found by installing all packages of python3.
3) The fix is based on the usage of
IMAGE_INSTALL, so it doesn't affect the users who do not want to use this feature (We disable it by default).
For me, it seems those should have a meta package, not a new install variable fo this.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 20 lines · Otavio Salvador
Quoted 19 lines · Hongxu Jia
Quoted 4 lines · Richard Purdie
This tells me what the change does. What it doesn't say is why we need this?
Its a fairly invasive set of changes but I don't see the usecase...
Hi Richard,
I am sorry not to say it clearly,
1) We have been asked many times on how to install all the PACKAGES of a recipe, we can only list them one by one in the RDPENDS (or
IMAGE_INSTALLand so on) currently, especially like dynamic generated packages (perl-modules, kernel-modules) which depends on many other packages, it is not easy to remember these package names for customer. It is helpful for user who does not take care the details that how many packages generated in a recipe, just want to directly install all of
them.
Quoted 8 lines
Quoted 6 lines
2) Providing a mechanism to install all the PACKAGES of a recipe is helpful to test all generated packages of a recipe could work, such as the defect of '[PATCH 3/4]' was found by installing all packages of python3.
3) The fix is based on the usage of
IMAGE_INSTALL, so it doesn't affect the users who do not want to use this feature (We disable it by default).For me, it seems those should have a meta package, not a new install variable fo this.
What meta package means? I am sorry I don't quite follow it.
//Hongxu
Quoted 1 line
Quoted 38 lines · Hongxu Jia
Quoted 37 lines · Otavio Salvador
Quoted 33 lines · Hongxu Jia
Quoted 5 lines · Richard Purdie
This tells me what the change does. What it doesn't say is why we need this?
Its a fairly invasive set of changes but I don't see the usecase...
Hi Richard,
I am sorry not to say it clearly,
1) We have been asked many times on how to install all the PACKAGES of a recipe, we can only list them one by one in the RDPENDS (or
IMAGE_INSTALLand so on) currently, especially like dynamic generated packages (perl-modules, kernel-modules) which depends on many other packages, it is not easy to remember these package names for
customer.
It is helpful for user who does not take care the details that how
many
packages generated in a recipe, just want to directly install all of
them.2) Providing a mechanism to install all the PACKAGES of a recipe is helpful
to test all generated packages of a recipe could work, such as the
defect
of '[PATCH 3/4]' was found by installing all packages of python3.3) The fix is based on the usage of
IMAGE_INSTALL, so it doesn't affect the
users who do not want to use this feature (We disable it by default).
Quoted 5 lines
Quoted 2 lines
For me, it seems those should have a meta package, not a new install variable fo this.
What meta package means? I am sorry I don't quite follow it.
Like we do for gstreamer; gstreamer1.0-plugins-good-meta, for example.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750