From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6460145511220379648 X-Received: by 10.223.162.138 with SMTP id s10mr128339wra.14.1504544019948; Mon, 04 Sep 2017 09:53:39 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.27.201 with SMTP id b192ls198555wmb.22.gmail; Mon, 04 Sep 2017 09:53:39 -0700 (PDT) X-Google-Smtp-Source: ADKCNb7NE1GA5PGhkD9OIFWbGE2IgMRXxobBARXlTnqOjsbbFievi460Vtw2IWUpc9f2a+RSQRmw X-Received: by 10.28.16.71 with SMTP id 68mr136036wmq.12.1504544019569; Mon, 04 Sep 2017 09:53:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504544019; cv=none; d=google.com; s=arc-20160816; b=RL1bvH7eOvnyUXdn6L36S1WBOIQ2thnv3IaBuZCa4EKL+s7O/AaC20Y/jKY6J5pphK pTA/xHe+Qa97B5ElpFWGXg8dWJbR5R1AiPCdtFPp9Q/HVnGq8bMLLqIaJAbOhajO5wZq MqY1s6PDehI2TFQsEFoxOXwJ4nyd75qEQE1xQZg6IQ94dhIQE43kOGDbqvFkOGi5t/DD 8/L1Mxbib0ywkUtJTbto80mc2XJ6s4DI50tReVdyPzFDkQOOVa2sSBH4F6jk9aSnYpSX k8qND4VOsVe8smclG8TlZ2hZNyPxqagzH106CC3GvDQJFTyzwyDulYXsFX3TnzqnywOm P3PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=a0SiaBPQuryhA1APUOf6Z6TEmCoDLxKq+U++ctenp/o=; b=ANntfP+1BHXnR74phA6YHEpb0U3GmquK4SG3lvJLu0knutI0qDFXwnPLt5UuLw6kkF Dwhv1lzfnYA/CzjR9SN8PE0HG4ZyYDlWn75jOjVwtasksyEAv7DbyQyMzjuPwv20nmIQ KYtlaslHMFpY60F4XG38vyRcAHLc2mPHFGMc5POxw0+c3F/MKyRaSvCTaZAseRyWYToP xNVBMNGJn75PcZAk/fAhEG0mGFxl9512kKvvB9aqg/jqwcfN03DvXWnjBVrXvic8ZgtI GGUNniVtmOQu9mFL9Iq64Ik5GsrhlA7BcWsW8BVU4yxM1za9ga3M3YZi6pjQBAR8Zcr6 XkMw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id y62si741457wme.1.2017.09.04.09.53.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 09:53:39 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v84GrdUb029829 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Sep 2017 18:53:39 +0200 Received: from md1f2u6c.ww002.siemens.net ([139.25.68.37]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id v84GrdPb004740; Mon, 4 Sep 2017 18:53:39 +0200 Subject: Re: [PATCH 5/6] meta/dpkg: add dpkg-custom class To: Alexander Smirnov , isar-users@googlegroups.com References: <356cb2c3f7dfead49d75580fdff10dfa8c41232e.1504119538.git.henning.schild@siemens.com> <183d261a-8b83-8dc0-09e7-80d80ce1cc15@siemens.com> <8e7d0e5f-ac47-7a83-6bdd-8c04654af5e7@ilbers.de> From: Jan Kiszka Message-ID: <8969769e-da51-dd04-0121-94e4498807c8@siemens.com> Date: Mon, 4 Sep 2017 18:53:38 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <8e7d0e5f-ac47-7a83-6bdd-8c04654af5e7@ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: egdRbNSDqWQF On 2017-09-04 18:30, Alexander Smirnov wrote: > > > On 09/04/2017 07:08 PM, Jan Kiszka wrote: >> On 2017-09-04 17:36, Alexander Smirnov wrote: >>> On 08/30/2017 10:03 PM, Henning Schild wrote: >>>> Issues: >>>> 1. full customizations of the images is hard to impossible to >>>> realize in a layer without touching Isar >>>> 1.1. there is no easy way to just copy a file into the image >>>> 1.2. configuration (passwords, groups, cfg-files changes) can not be >>>> done in a layer, there is no way too hook into multistrap or the >>>> configure-script >>>> >>>> Change: >>>> Introduce a class that lets users create custom debian packages on the >>>> fly, without having to create a /debian directory and actually >>>> building. >>>> That allows you to pull in debian-dependencies, you could have a >>>> package that has no content and is just there to install what you need >>>> for a feature of your product. >>>> Using package hooks (preinst, postinst ..) you can configure pretty >>>> much >>>> all you want when installing the package. >>>> The package can contain actual payload as well, basically any files >>>> that >>>> come from "somewhere else". Say binary data like wallpapers, sound >>>> files >>>> or application binaries. >>>> >>>> Impact: >>>> This patch addresses the metioned issue in a way that uses debian >>>> mechanism. All the customizations will enjoy features like >>>> - collission protection (multiple packages providing the same file) >>>> - config file protection >>>> - versioning and the ability to deploy your changes in an updateable >>>> way >>>> >>>> This patch introduces a major new feature to Isar. >>>> >>>> This class introduces a new class for building debian packages on the >>>> fly. They can basically contain anything from random sources, where >>>> building happens outside of Isar. It also allows to create >>>> meta-packages >>>> that contain nothing but pull in dependencies, once all our packets >>>> come >>>> in via multistrap that will come in handy. >>>> For rootfs configuration you would use post- and pre- scripts just like >>>> regular debian packages do. >>>> >>> >>> Good idea. >>> >>>> Signed-off-by: Henning Schild >>>> --- >>>>    meta/classes/dpkg-custom.bbclass | 57 >>>> ++++++++++++++++++++++++++++++++++++++++ >>>>    1 file changed, 57 insertions(+) >>>>    create mode 100644 meta/classes/dpkg-custom.bbclass >>>> >>>> diff --git a/meta/classes/dpkg-custom.bbclass >>>> b/meta/classes/dpkg-custom.bbclass >>>> new file mode 100644 >>>> index 0000000..e4e743f >>>> --- /dev/null >>>> +++ b/meta/classes/dpkg-custom.bbclass >>>> @@ -0,0 +1,57 @@ >>>> +# This software is a part of ISAR. >>>> +# Copyright (C) 2017 Siemens AG >>>> + >>>> +inherit dpkg >>>> + >>>> +DEBIAN_DEPENDS ?= "" >>>> +MAINTAINER ?= "FIXME Unknown maintainer" >>>> + >>>> +D = "${WORKDIR}/image/" >>>> + >>>> +# Populate folder that will be picked up as package >>>> +# TODO this should be called 'do_install' >>>> +do_populate_package() { >>>> +    bbnote "Put your files for this package in ${D}" >>>> +} >>>> + >>>> +addtask populate_package after do_unpack before do_deb_package_prepare >>>> + >>>> +# so we can put hooks etc. in there already >>>> +do_populate_package[dirs] = "${D}/DEBIAN" >>>> + >>>> +do_deb_package_prepare() { >>>> +    cat<<-__EOF__ > ${D}/DEBIAN/control >>>> +        Package: ${PN} >>>> +        Architecture: `dpkg --print-architecture` >>>> +        Section: misc >>>> +        Priority: optional >>>> +        Maintainer: ${MAINTAINER} >>>> +        Depends: `echo ${DEBIAN_DEPENDS} | tr '[:blank:]' ','` >>>> +        Version: ${PV}+isar >>>> +        Description: ${DESCRIPTION} >>>> +    __EOF__ >>>> +    for t in pre post >>>> +    do >>>> +        for a in inst rm >>>> +        do >>>> +            chmod -f +x ${D}/DEBIAN/${t}${a} || true >>>> +        done >>>> +    done >>>> +} >>>> + >>>> +addtask deb_package_prepare after do_populate_package before >>>> do_deb_package_conffiles >>>> + >>>> +do_deb_package_conffiles() { >>>> +    CONFFILES=${D}/DEBIAN/conffiles >>>> +    find ${D} -type f -path '*/etc/*' | sed -e 's|^${D}|/|' >> >>>> $CONFFILES >>>> +    test -s $CONFFILES || rm $CONFFILES >>>> +} >>>> + >>>> +addtask deb_package_conffiles after do_deb_package_prepare before >>>> do_deb_package >>>> + >>>> +do_deb_package() { >>>> +    sudo chown -R root:root ${D}/DEBIAN/ >>>> +    sudo dpkg-deb --build ${D} ${WORKDIR} >>>> +} >>>> + >>>> +addtask deb_package after do_deb_package_conffiles before do_install >>>> >>> >>> If I got this correctly, the difference from dpkg-debian flow is that >>> you generate 'debian' folder on the fly. So: >>> >>> 1. Why we need another do_deb_package, while do_build from dpkg class >>> does the same? >>> >>> 2. Can we just add optional task to generic pipeline which generates >>> debian folder? Or make it as a part of do_build: if [ ! -d ${D}/debian >>> ]; then blablabla. >>> >> >> I'm not too deep into the details here, but the general considerations >> should be here: >> >> - Do both classes share enough code to unify them? > > From my POV - yes. > >> - Is it easy enough for the user to specify and the class to derive the >>    mode of operation when there is only one class? > > That's, for example, how autotools work in Yocto. If you need to run > autoconf/configure in your recipe, you just: > > inherit autotools > > and respective tasks are added to your pipeline. So in current case, > user could inherit some 'debian-gen' class, which adds task that > generates debian folder for your project. > > In my opinion, the pipeline should stay the same, but some tasks could > be included/excluded on demand. IOW: keep dpkg.bbclass, derive dpgk-gen.bbclass from it in a way that it overwrites/expands the former to generate the meta data. I suppose one has to look at the resulting code to validate if that is beneficial, but the reuse may indeed increase once we start building from source with the generator approach as well - something Henning was already talking about. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux