From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6460145511220379648 X-Received: by 10.223.141.206 with SMTP id o72mr330830wrb.25.1504186783364; Thu, 31 Aug 2017 06:39:43 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.168.77 with SMTP id r74ls1334560wme.12.gmail; Thu, 31 Aug 2017 06:39:42 -0700 (PDT) X-Google-Smtp-Source: ADKCNb4h7bP2w2wrmV6UUy0SVbIKBXk+ePbZyeQQ154d1VW0HD4ldWWcKA2gnKwsNSgga8JI6ox+ X-Received: by 10.28.153.130 with SMTP id b124mr28986wme.18.1504186782936; Thu, 31 Aug 2017 06:39:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504186782; cv=none; d=google.com; s=arc-20160816; b=vC0rbLIH3QwKZAm6WXU4JxWzZ8oGKf1pyXgfq4frzAfHwJdJkRjSiCg+Hpe4o2/TlK efgjoQcAWVCC/7n0auIlGE247o37e/wvbB8MH1wiiWVKgJkRNMbtXTTX+klU3Qv1Il83 YxTGxwf1o5tVawyStLVCJOJ65AkY6hSkjN1MAvfxnOdqt3zUyVWTnDFoew50+1UesYOg i3FPdMy3YqzcnCIVeCokfFqoHbDDB5sgojh5V+tewly4RK1MmuDvF6GsXAhnT0xa7h2S 12qbNKYupet4zAp8YDFw3YmByoWcYv2MdU1skF/yrL8A+vp3mvcnk2mjvQ67hPSdMPn6 1WZw== 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=5uiY3aa/jAx1dVIe3eESEsvpZA0ltDtg6QzTbsOnCg4=; b=NEhvGbtrz4+KqSKQgHYkx5UJ7jGKF2Oq3Rgnr9K7jiJtXv5R8NcqgpRg5XpCEhqaJb MLoRX8Iez51v50GDC3uVIEyZM/u5fxX7u6sc3khGmk0DtyePScgOM3Q/32PNDq3lQr9b Li0UUrkmtcPonM2jGyVS3WpK+E/Z9sLet3ah1qgnXRxssuoXB6d12rHTBZa5U/KaYorw Xc4ZB5th9rEBGqByWiFGIjx+HxC1ikWEwwDElV/6oQuiHssR3ygYdIad6bvbGZJWYJKY MpjJH/6jYGpwRZhH1sY3qJzw+TIf7Qi9od1efTgBdxsKjUeI4ti1VUOYbbm1q87ywbjK LJNw== 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 z83si10760wmc.3.2017.08.31.06.39.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 06:39:42 -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 mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v7VDdfX3022161 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 15:39:41 +0200 Received: from md1em3qc ([139.25.68.40]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v7VDdfP1016059; Thu, 31 Aug 2017 15:39:41 +0200 Date: Thu, 31 Aug 2017 15:39:44 +0200 From: Henning Schild To: Claudius Heine Cc: Jan Kiszka , , Alexander Smirnov , Christian Storm , Claudius Heine Subject: Re: [PATCH 5/6] meta/dpkg: add dpkg-custom class Message-ID: <20170831153944.3e475571@md1em3qc> In-Reply-To: <7c037e42-d6d5-db90-74e8-0c9b2ee94d2d@siemens.com> References: <356cb2c3f7dfead49d75580fdff10dfa8c41232e.1504119538.git.henning.schild@siemens.com> <75fe7dd9-7cf0-9f10-7060-64b69fa38194@siemens.com> <4ea25dde-acf8-f8e7-1153-9c33cabef4e3@siemens.com> <20170831113233.02d8c5b5@md1em3qc> <7c037e42-d6d5-db90-74e8-0c9b2ee94d2d@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: rFZhZsw1wN9h Am Thu, 31 Aug 2017 14:14:10 +0200 schrieb Claudius Heine : > On 08/31/2017 11:32 AM, Henning Schild wrote: > > Am Thu, 31 Aug 2017 10:42:53 +0200 > > schrieb Jan Kiszka : > > > >> On 2017-08-31 10:38, [ext] Claudius Heine wrote: > >>> Hi > >>> > >>> On 08/30/2017 09:03 PM, [ext] 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. > >>>> > >>>> Signed-off-by: Henning Schild > >>>> --- > >>>> meta/classes/dpkg-custom.bbclass | 57 > >>>> ++++++++++++++++++++++++++++++++++++++++ > >>>> 1 file changed, 57 insertions(+) > >>>> create mode 100644 meta/classes/dpkg-custom.bbclass > >>> > >>> Also not a big fan of this name. 'custom' is a bit too unspecific > >>> for what it does. I get that your idea that those packages are > >>> *custom* made, but at the same time, so are all the packages that > >>> are directly created within isar. > >>> > >>> I liked the old 'dpkg-bin' name more, but maybe even this is a bit > >>> to unspecific. How about 'dpkg-plain'? That describes better that > >>> those packages are very simple, created impromptu without much to > >>> it, IMO. > >> > >> How about dpkg-wrap, because this wraps existing stuff as-is into > >> debian package? > > > > I explained the new names in the cover letter. dpkg-bin can not be > > used because that suggests that we do not compile in this class. As > > of today we do not but i can imagine a future where we do, just > > without the debian/ directory. > > So now dpkg-src also does not match anymore, i think. > > > > Any suggestions for both names taking the custom-compile into > > account? > > I would still use 'dpkg-plain' for 'dpkg-custom' and 'dpkg-src' or > 'dpkg-src-dir' for 'dpkg-debian'. Ok, how about -raw and -src ? > Customization of the current implementation of the 'dpkg-custom' > class is a bit unusual, since it adds tasks before the do_install > step. Maybe it needs to be refactored a bit so that packaging is done > after the 'do_install' task and then it packages just everything that > is in '${D}' while using the preinst and the other hooks from the > WORKDIR. Maybe have an additional directory for them, just so that > its a bit cleaner. > > As I pointed out in message > <60d3f1ca-67a1-9c43-07f6-d2d89e4c2e51@siemens.com>, we should fix the > general task pipeline for this. I would propose something like this: > > fetch, unpack, configure, compile, install, package, populate_repo That is another discussion about names. The patch has a note that the task where D is populated should be called do_install, but do_install is taken and can not be used. do_install currently is what you would like to call populate_repo About the "make all" and do_build please continue the following discussion if you think it is still relevant. https://groups.google.com/d/msg/isar-users/UyEQmcTlHtw/UnrOh3JnBQAJ > So 'dpkg-custom'/'dpkg-plain' should only contain the 'do_package' > and their subordinate tasks. I think logically that is the case right now, the names are just different. If i am wrong please point me to the logical problem, not the name. > Why would the 'dpkg-debian' class need a custom compile step? Since > the /debian directory already contains instructions to build the > software. If something needs to be done before or after compilation > there, then just modifiy the configure or install task. It is dpkg-custom/-raw that could gain a custom compile step. That is why i do not want to call it -bin today. Henning > Cheers, > Claudius >