On 16/02/2017 05:44, Richard Purdie wrote:
On Wed, 2017-02-15 at 18:33 +0100, Geoffrey Levillain wrote:
There is often a need to add configuration files specific to an
image,
to simplify this process we can use a task.
Fetching is set as noexec for images, but there is a need to fetch
files
here. This class permit to use do_fetch, do_unpack and do_patch in
order
to get your image-specific overlays to install.
Signed-off-by: Geoffrey Levillain <[email protected]>
---
meta/classes/image_overlay.bbclass | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 meta/classes/image_overlay.bbclass
diff --git a/meta/classes/image_overlay.bbclass
b/meta/classes/image_overlay.bbclass
new file mode 100644
index 0000000000..93c1ea6f9f
--- /dev/null
+++ b/meta/classes/image_overlay.bbclass
@@ -0,0 +1,24 @@
+# Enable SRC_URI for images and use it to install overlays
+
+# Let these task be executed to fetch overlay
+unset do_fetch[noexec]
+unset do_unpack[noexec]
+unset do_patch[noexec]
At the same time as you're submitting this, I'm seriously considering a
change where instead of noexec, we'd deltask these tasks. The reason
being I'm not very keen on subverting the package manager and I'm not
convinced this is a particularly desirable way to be altering the
rootfs.
There are various files in images that are provided by the package
manager and that are ok to modify. most files in /etc are in that category.
The idea here is to be able to have generic (image independant)
packages, but to override the package configuration with custom ones at
image-generation time.
on a normal (desktop) distribution, the user writes his configuration
files, but in a deep-embedded useage, there is no user.
A bbappend (overriding the config file at package-build time) would seem
a better solution at first, but this doesn't work because it forces to
have a different package for each image type. Again we are trying to
particularize each image, while keeping the distribution itself generic.
I hope this helps clarify why we do this at the image level and not the
package. packages are shared between images, but configuration is
altered per-image.
Jérémy
+# Add a task to install the overlay
+# (content of folders listed in OVERLAY_ROOT_DIRS is copied in
rootfs)
+addtask install_overlay after do_unpack do_patch do_rootfs before
do_image
+fakeroot do_install_overlay() {
+ for dir in ${OVERLAY_ROOT_DIRS}; do
+ if [ ! -d "${WORKDIR}/${dir}" ] ; then
+ bbfatal "${dir} not found, please check your
OVERLAY_ROOT_DIRS and SRC_URI variables."
+ fi
+ cp -dr --no-preserve=ownership "${WORKDIR}/${dir}"/*
"${IMAGE_ROOTFS}"
+ done
+}
+do_install_overlay[depends] += "virtual/fakeroot-
native:do_populate_sysroot"
+do_install_overlay[dirs] = "${IMAGE_ROOTFS}"
+do_install_overlay[umask] = "022"
+do_install_overlay[vardeps] += "OVERLAY_ROOT_DIRS"
+
+SSTATETASKS += "do_install_overlay"
Except this isn't an sstate task? There is no setscene task variant of
the main task. There are no sstate variables set either...
Cheers,
Richard
--
Logo <http://www.smile.fr/>
20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr <http://www.smile.fr/>
*Jérémy ROSEN*
Architecte technique
Email : [email protected] <mailto:[email protected]>
Tel : +33141402967
Facebook <https://www.facebook.com/smileopensource> Google%2B
<http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn
<https://www.linkedin.com/company/smile> Twitter
<https://twitter.com/GroupeSmile>
bandeaux_mail
<http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature&utm_medium=email&utm_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
