Re: [PATCH 5/6] meta/dpkg: add dpkg-custom class

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 31 Aug 2017 14:14:10 +0200
schrieb Claudius Heine <claudius.heine.ext@siemens.com>:

> On 08/31/2017 11:32 AM, Henning Schild wrote:
> > Am Thu, 31 Aug 2017 10:42:53 +0200
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >   
> >> 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 <henning.schild@siemens.com>
> >>>> ---
> >>>>    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
>