From: "David Nyström" <david.c.nystrom@gmail.com>
To: Robert Yang <liezhi.yang@windriver.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [RFC - WIP PATCH 1/1] image.bbclass: create binary pkg for image recipe
Date: Thu, 03 Jul 2014 10:19:33 +0200 [thread overview]
Message-ID: <53B51215.7060605@gmail.com> (raw)
In-Reply-To: <170029dfcde1cb5c69c5e8c82efa9f223deaf797.1404292676.git.liezhi.yang@windriver.com>
On 2014-07-02 11:25, Robert Yang wrote:
> * Benefits
> We can known the image's RDEPENDS outside the build environment, and
> can use a third part installer such as anaconda to install the packages.
> It's hard to get the ROOTFS_POSTPROCESS_COMMAND outside the build
> environment, now the shell function can be added to postinst, and will
> show a warning for the python function. We have two python functions
> atm: write_package_manifest and write_image_manifest, we don't need them
> in the binary pkg.
>
> * Brief design:
> - Set the RDEPENDS and create the package as other regular recipes.
>
> - Translate the ROOTFS_POSTPROCESS_COMMAND to postinst
> do_install[postfuncs] += "get_rootfs_postprocess_command"
>
> The get_rootfs_postprocess_command() will emit the shell script to
> /usr/share/${PN}, and the pkg_postinst_${PN} will run it when do the
> install.
>
> * Fixed:
> RDEPENDS -> RDEPENDS_${PN}, the similar to RRECOMMENDS
>
> * Tested on rpm, dep and ipk
>
> * TODO:
> - Create the binary pkg optionally rather than default ?
> [YOCTO #6463]
Interesting approach.
Image binaries were created before
poky-commit:6706c7bdd2de6e0e447d90062e74a718a8d31778,
but this feature was removed.
A similiar approach has been rejected before:
http://lists.openembedded.org/pipermail/openembedded-core/2013-December/087474.html
I ended up with a fork of image.bbclass for images I needed available as
meta-packages.
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
> meta/classes/image.bbclass | 91 +++++++++++++++++++++++---
> meta/recipes-core/meta/buildtools-tarball.bb | 2 +-
> 2 files changed, 83 insertions(+), 10 deletions(-)
<SNIP>
> +
> + bb.note('Fix build path in %s' % postinst)
> + # Remove the IMAGE_ROOTFS prefix
> + fix_cmd = "sed -i -e 's:%s::g'" % d.getVar('IMAGE_ROOTFS', True)
> + # Remove the STAGING_DIR_TARGET prefix
> + fix_cmd += " -e 's:%s::g'" % d.getVar('STAGING_DIR_TARGET', True)
> + # Comment out the STAGING_DIR_NATIVE related lines
> + fix_cmd += " -e 's:\(^.*%s\):#\\1:'" % d.getVar('STAGING_DIR_NATIVE', True)
> + # Comment out the PSEUDO related lines
> + fix_cmd += " -e 's:\(^export .*PSEUDO\):#\\1:'"
> + # Comment out the username related lines
> + fix_cmd += " -e 's:\(^export .*%s\):#\\1:'" % d.getVar('USER', True)
> +
Why are you commenting out these vars ?
Perhaps it would be better to fix the ROOTFS_POSTPROCESS_COMMANDs, and
rely on a sane environment ?
> + fix_cmd += " %s" % postinst
> + subprocess.call(fix_cmd, shell=True)
> +
> + os.chmod(postinst, 0755)
> +
> + with open(postinst_list, 'a') as plist:
> + plist.write("%s\n" % postinst.replace(d.getVar('D', True), ''))
> +}
> +
> +pkg_postinst_${PN} () {
You need to check if your running on target here.
> + listfile = "${datadir}/${PN}/postinst_list"
> + if [ -s $listfile ]; then
> + for script in `cat $listfile`; do
> + echo "Running $script..."
> + /bin/sh $script
> + if [ $? -ne 0 ]; then
> + # Allow the failure rather than re-install the package
> + # since the script can be manualy run
> + echo "ERROR: failed to run $script" >&2
> + echo "ERROR: please fix $script and manually run it" >&2
If the ROOTFS_POSTPROCESS_COMMANDs do follow the same rules as other
postinstalls, you could potentially defer executing to first boot when
errors occur. (run-postinst)
> + true
> + fi
> + done
> + fi
> +}
> +
> do_fetch[noexec] = "1"
> do_unpack[noexec] = "1"
> do_patch[noexec] = "1"
> do_configure[noexec] = "1"
> do_compile[noexec] = "1"
> -do_install[noexec] = "1"
> do_populate_sysroot[noexec] = "1"
> -do_package[noexec] = "1"
> -do_packagedata[noexec] = "1"
> -do_package_write_ipk[noexec] = "1"
> -do_package_write_deb[noexec] = "1"
> -do_package_write_rpm[noexec] = "1"
>
> addtask rootfs before do_build
> # Allow the kernel to be repacked with the initramfs and boot image file as a single file
> diff --git a/meta/recipes-core/meta/buildtools-tarball.bb b/meta/recipes-core/meta/buildtools-tarball.bb
> index 62e1e0b..7501525 100644
> --- a/meta/recipes-core/meta/buildtools-tarball.bb
> +++ b/meta/recipes-core/meta/buildtools-tarball.bb
> @@ -45,7 +45,7 @@ TOOLCHAIN_HOST_TASK ?= "\
>
> TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-buildtools-nativesdk-standalone-${DISTRO_VERSION}"
>
> -RDEPENDS = "${TOOLCHAIN_HOST_TASK}"
> +RDEPENDS_${PN} = "${TOOLCHAIN_HOST_TASK}"
>
> EXCLUDE_FROM_WORLD = "1"
>
>
next prev parent reply other threads:[~2014-07-03 8:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 9:25 [RFC - WIP PATCH 0/1] image.bbclass: create binary pkg for image recipe Robert Yang
2014-07-02 9:25 ` [RFC - WIP PATCH 1/1] " Robert Yang
2014-07-03 8:19 ` David Nyström [this message]
2014-07-03 8:29 ` Robert Yang
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=53B51215.7060605@gmail.com \
--to=david.c.nystrom@gmail.com \
--cc=liezhi.yang@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.