From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6460145511220379648 X-Received: by 10.25.169.1 with SMTP id s1mr757557lfe.29.1505117966284; Mon, 11 Sep 2017 01:19:26 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.18.219 with SMTP id 88ls185748ljs.39.gmail; Mon, 11 Sep 2017 01:19:25 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAkKpTW5vUpKc42rOYLqrlUUci7AIMjQTnsGIHKkOYVTwIB0GuUBS9gF4W82IDrBImWPM8R X-Received: by 10.25.22.24 with SMTP id m24mr720072lfi.36.1505117965737; Mon, 11 Sep 2017 01:19:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505117965; cv=none; d=google.com; s=arc-20160816; b=lA6wtcfi2WayoAVePh9nbhzDwH3H1oK0/Nx5CcSz2kw9pu7SjYkWmH/1QnSQ0AT6QD A85Af2YgPYKrzH54nOnqDOl2aRbYnO3psQnVN3C4eVlw9ROZ40moTyLxdD8ceIV1xiOZ HdkDXTpxF8sNcYggGGCW/O/XERT6M4TmB94ChxJ7KGeMOi+6NqgPjTGeAj2WgiPh3ZOC KppN0+g0laoxJwgS6JSqOAmCpNq+X1eV+z6gqIGwLMG1tQ5WyndolV2/Ts0ClT9fH++O wEZcJ83zZ7AFzHV2zpc/nwE7AgxXBkaxRhZG+FjqND6i0iRSFMLeLMTVC19htGX3wVau 59jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=E8g0jguAszCONX95qpAbiYIKdRWZSBxhZkTgGYmAY/I=; b=ARG8TyIDoDqpxMjCnX7/AwQffFM5XPjCOVrCmfoW9dKnQYXFe/nAXvSZ1tlbakt2Q9 sZFmg9I9eD3HlIBEqNBZ1r1jqX297EWeFObSyh0ucpNRu3wRo4KtYVzL+ouf8FRxPKy4 vLZUgqogj161zhgcKoz+9gQlmVd8baeX3wzyq7N7yzyHWYWrxX6NIXUb2rd9YGZJOctv NF53VldI/f0wpoRyQQcuVJnCc3gKN7YvU/v9EOJoKF8qJ0f+5vyP0PZbl0GspE8YHkNL QUiOKRnJ0hQ1UahXYOGlMbZKvckzP1OInODHh24P4xkQbEkcvC30bgYNKjnC2Wrzc2HA bRnA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id q145si260281wme.4.2017.09.11.01.19.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 01:19:25 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v8B8JPRX024830 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Sep 2017 10:19:25 +0200 Received: from md1em3qc ([139.25.68.40]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id v8B8JPMH006327; Mon, 11 Sep 2017 10:19:25 +0200 Date: Mon, 11 Sep 2017 10:19:37 +0200 From: Henning Schild To: "[ext] Claudius Heine" Cc: Alexander Smirnov , Subject: Re: [PATCH 5/6] meta/dpkg: add dpkg-custom class Message-ID: <20170911101937.50b5c132@md1em3qc> In-Reply-To: <303e4092-fb88-3115-b770-44dc7cdc2420@siemens.com> References: <356cb2c3f7dfead49d75580fdff10dfa8c41232e.1504119538.git.henning.schild@siemens.com> <303e4092-fb88-3115-b770-44dc7cdc2420@siemens.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: tCCfgO/EnJvc Am Mon, 11 Sep 2017 10:13:02 +0200 schrieb "[ext] Claudius Heine" : > Hi, > > On 09/04/2017 05:36 PM, 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? > > Why not? 'do_build' is a very bad name, because it not really > describes anything specific and if you have multiple tasks with good > names like 'deb_package' (while I still would prefer 'package_deb') > that do just one job each, then its much easier to recognize the > tasks when calling 'bitbake -c liststasks ..' and its simpler to > extend the pipeline in each recipe as needed. > > 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. > > No, please not part of the 'do_build' task! Thats exactly the reason > why 'build' is not a good name, because it describes everything and > nothing and now developers are ensnared by its name to put everything > in it. And you agree that one big task that rules the world is just > very bad design. Every task should be very simple and do just one > thing. > > About the optional task inserted into the generic pipeline: I don't > really see the benefit. I currently tend to prefer them to be > separated and I see different arguments on both sides. My current > view of those packages where the 'DEBIAN' directory is created on the > fly are that they aren't clean packages. The 'right' way to do this > is to have debianized sources or a patch that adds the right 'DEBIAN' > directory to the sources. This here is just a useful shortcut for > debianizing the sources. I guess you should read the whole thread and prepare your reply based on all information. Henning > Cheers, > Claudius >