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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox