From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6460145511220379648 X-Received: by 10.46.0.222 with SMTP id e91mr148621lji.21.1504542652841; Mon, 04 Sep 2017 09:30:52 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.18.81 with SMTP id 78ls446045wms.8.canary-gmail; Mon, 04 Sep 2017 09:30:52 -0700 (PDT) X-Google-Smtp-Source: ADKCNb6mmL9e4bdIbDeQ5q0YQ8jB8Rx9ggxjA0V+F8jv0FGQqlNqSSQNWiILRvz+aV7izKk/+/gH X-Received: by 10.28.158.23 with SMTP id h23mr135480wme.5.1504542652400; Mon, 04 Sep 2017 09:30:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504542652; cv=none; d=google.com; s=arc-20160816; b=Bj5ExIH6Vgz21lMmNebPV3U1EErnFq7MERze3zIQsf77o8LqIWg7jTfvURDsrFcVx/ LlOQkcijnH+hiA4cdwfITrq0L++o+QAIl6Rkx2b4wiIaWclef3gnCk3/ASMHclI1OMnl y2WVKDUeXBCVgDrgQALlZS5hY7JWStSZ4FjaoCX9dAvKDdj2QfLj8KHfey+XiIUTamrG eLGDS46I6HJ9rmLbZcP3Esn7avQhTWNFnjQJJiq6j1w1CwWP/RVMU1jhYzKMX4Krn3U6 26zl8c8u/rjEmIHUkNd1lUxAflJmiDep3r9zpImWsRudqDZOpX7CTIdGe20ym2IqPbNS 3jIw== 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=YE4nDJE/mXleP5OuFfBxwD8/CnzU6ICSBsMa2cU48O8=; b=JmO4r+klFUuMh8lcPNTFOFFEdfXRSt+e0jOJXB82959JVXqilN82c2YZgnYHUxcv7u hegJXG/DyCbtPEe0Kxz9WEJhmHVLYGSWNzpY/J6N8RRNul2ulNxHQMQVGp7u+RHIuJrB O7CWhZjcKv7gJPpB1/jUZmL7DNdFOiCNALWZLKIyxkvMp+baAXSVh/MyIv5AqgWfpvSA 7M+n8F1eH5jQI5iZcQhXYVxhcPtNihUtkR+Nvndf4YbXrEMpZIysSoFX15e2DlqgAP+M jrJOhfEdQ/hfTIxJN48Dnhf9Mky5hLgxuokyt4SumtxdWsldGqOadOUibADz612epPto odXg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id z62si54210wmc.5.2017.09.04.09.30.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 09:30:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v84GUnVp009213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Sep 2017 18:30:50 +0200 Subject: Re: [PATCH 5/6] meta/dpkg: add dpkg-custom class To: Jan Kiszka , isar-users@googlegroups.com References: <356cb2c3f7dfead49d75580fdff10dfa8c41232e.1504119538.git.henning.schild@siemens.com> <183d261a-8b83-8dc0-09e7-80d80ce1cc15@siemens.com> From: Alexander Smirnov Message-ID: <8e7d0e5f-ac47-7a83-6bdd-8c04654af5e7@ilbers.de> Date: Mon, 4 Sep 2017 19:30:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <183d261a-8b83-8dc0-09e7-80d80ce1cc15@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: wUZzvdWVxUNa 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. Alex