From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6460145511220379648 X-Received: by 10.223.185.55 with SMTP id k52mr536373wrf.23.1505117583553; Mon, 11 Sep 2017 01:13:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.47.207 with SMTP id v198ls1007729wmv.10.gmail; Mon, 11 Sep 2017 01:13:03 -0700 (PDT) X-Google-Smtp-Source: ADKCNb5BWHt5f2LKhyBjRZoxecbl8tNQ/TCiFJN/R2cmMaaXwjYs4wDuJ3r8QxRp0ozITBXKfO6F X-Received: by 10.223.166.240 with SMTP id t103mr539139wrc.31.1505117583232; Mon, 11 Sep 2017 01:13:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505117583; cv=none; d=google.com; s=arc-20160816; b=UP15NjSrkAQce72xcwy+8r+OIF2a0HpgvpZAH57TUANspv/SOOncuxEbXcqyy64AUW UL3miln4gf9q7kbPQS+JjpoGkw0Wv2PNDnZILxSQcu+HrC5pPSHIE6hjT4tW9/Ttk/9r 2JOp89L+s3uspVKpEe8bXhnLN8x4sL73MUoAr5OwzVnSRhv7usqWyBB7e8+F1vBVDSb0 OUS/60jgICJhGpdfgHm+bMjicy1U8Bj15Dl43kkOzgLNDpMBkejTYg8xYht22JcUSVgV eXxnIUsTrRG8FCB7TiDC2Cu+GtqOIqLchO2ZlmokVCtCWdD0IaRB5A/HcEsTM7u8qhZ2 YBYA== 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=dmzIzlUZ+IyR4eh5JgpXzwTasobniFLODQq8/VYghNQ=; b=jgcyyKUw5Qgkj0Q3U/m5HsOsZ+bMOzSGmOxgqKCB12Ec7Uhbh5YcQKly0WfG0ENMf7 qRRjQeCVjwbpv3TjsqL8r7IxBpJQPKhor66qOwOkSnHW9ApMAaFnkmucPm+g7FObbCzs Tdf7f6iFGKuvrojJssWWSMmhCqpxlnOBh/vv61/bCTJQSFRSlJCFoiewsbNujpYZGp6s xbU2M47qdbVtNFOXAdMh4CzHDcaLXxmt0x2ZLoAce+Ep9er4fs4pdIJFOPJMqi7qi+yV uvXxWa0TxZ2urpYoAocsfxx+e0RY9zLWiMoRDCpxoksEcOfoGnD8XeKGg9N75qYuSuZ8 0sBw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 194.138.37.39 is neither permitted nor denied by best guess record for domain of claudius.heine.ext@siemens.com) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id c142si549896wmh.3.2017.09.11.01.13.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 01:13:03 -0700 (PDT) Received-SPF: neutral (google.com: 194.138.37.39 is neither permitted nor denied by best guess record for domain of claudius.heine.ext@siemens.com) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 194.138.37.39 is neither permitted nor denied by best guess record for domain of claudius.heine.ext@siemens.com) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id v8B8D2fc023750 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Sep 2017 10:13:03 +0200 Received: from [139.25.68.223] (linux-ses-ext02.ppmd.siemens.net [139.25.68.223]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id v8B8D2ow027233; Mon, 11 Sep 2017 10:13:02 +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> From: Claudius Heine Message-ID: <303e4092-fb88-3115-b770-44dc7cdc2420@siemens.com> Date: Mon, 11 Sep 2017 10:13:02 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 9XP2LAsbfm9S 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. Cheers, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de