From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6460145511220379648 X-Received: by 10.25.196.138 with SMTP id u132mr157412lff.20.1504858808127; Fri, 08 Sep 2017 01:20:08 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.25.142.89 with SMTP id q86ls100635lfd.27.gmail; Fri, 08 Sep 2017 01:20:07 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBsfKqg33EIXpjsRRs8Rc2nwBIjJvwGgjvtRFvmzE3LZUNqwKrtqwSbHYfZUViMc7jG3j/m X-Received: by 10.46.83.13 with SMTP id h13mr142825ljb.40.1504858807860; Fri, 08 Sep 2017 01:20:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504858807; cv=none; d=google.com; s=arc-20160816; b=RZmwokhE6cbk9gao5+DQRFk4G0OL6N/sdTga7dJjfr1S2KVW3OIFgvIG39JaNRgYsH +ATLKiCBlFSdwNRya/T5ZPx6t0PeueUNfOIxBBOnpbfPho524qpWNzZeWn+VpFTyv5jW WGAKUW8wjHosoN+wwOq4opcJ9iHKPhlZrs8SlMAXnkdjobro6IImusrdrd1x7Gc97Iw2 DGNpx7wZCAN1nMsqh53dhs7bWilhLFoHG5OHzANnmPu/Cst7FP6ubdif8t+1Ur1QnWur 43qpYXAzeaB4ezDIs3xrXLUDzEWLpxvmUD3Z7zSRKbHRawjWBNje4iIkfecs/w68Z59m AFKg== 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=hoDyhp3t9x1oB3BFDJSig+wm6lHVI6JJx9V/EktF3Cg=; b=MGM/PjQbFAiTwVCgISiFBXH9kIf821iPXQX6Iws77gA+ahoVJorSSxEjjcI6wmlCFR 5kwnJDzO6PpyZe+9oo8AX6upuHo8qbGDVTDsi1e8iKHBQCbzfRWrkqCF0TA5L0vCqyqm hBFNBjB4qFw9kpnztyx09Ga9AfrzPrdXaWU6xgsrWcvHSGxR2gtytbK8a5M0uYi+SDcU V9Xg9VfyV+p5NtMfu/Kj241T5tUF8EwrqMath2p5ac1D83FZjkl2OC1oJ9hgTammeW4x dyi8JaEezNkj+G1OAN45+a18gf0MpknqE7BSF+naEhUIgYnSgmx6CZfmoC8p1CvzLsTG QhXQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 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 david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id r8si145849wma.4.2017.09.08.01.20.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 01:20:07 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 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 david.siemens.de (8.15.2/8.15.2) with ESMTPS id v888K7t7022920 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 8 Sep 2017 10:20:07 +0200 Received: from md1em3qc ([139.25.68.40]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id v888K6cQ020204; Fri, 8 Sep 2017 10:20:06 +0200 Date: Fri, 8 Sep 2017 10:20:16 +0200 From: Henning Schild To: Alexander Smirnov Cc: Jan Kiszka , Subject: Re: [PATCH 5/6] meta/dpkg: add dpkg-custom class Message-ID: <20170908102016.73b2513d@md1em3qc> In-Reply-To: <8e7d0e5f-ac47-7a83-6bdd-8c04654af5e7@ilbers.de> References: <356cb2c3f7dfead49d75580fdff10dfa8c41232e.1504119538.git.henning.schild@siemens.com> <183d261a-8b83-8dc0-09e7-80d80ce1cc15@siemens.com> <8e7d0e5f-ac47-7a83-6bdd-8c04654af5e7@ilbers.de> 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: TRIhVyIW489B Am Mon, 4 Sep 2017 19:30:43 +0300 schrieb Alexander Smirnov : > 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. I do not think so. Because it is not about 'debian'-izing the sources before do_build but rather replacing do_build with a series of tasks that use other debian tools. So it is an orthogonal workflow from the source to the debian package. Henning > > > - 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 >