[OE-core] [PATCH v2 2/3] image_overlay.bbclass: Add possibility to install overlays to image

Fri Feb 17 10:42:42 UTC 2017

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 <geoffrey.levillain at smile.fr>
>> ---
>>   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 : jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Logo.png
Type: image/png
Size: 3775 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Facebook.png
Type: image/png
Size: 835 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Slideshare.png
Type: image/png
Size: 967 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinkedIn.png
Type: image/png
Size: 816 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Twitter.png
Type: image/png
Size: 989 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OW_devient_Smile_ECS.png
Type: image/png
Size: 83679 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0019.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eco.png
Type: image/png
Size: 267 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170217/aadbdc51/attachment-0020.png>