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

[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'.

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

So 'dpkg-custom'/'dpkg-plain' should only contain the 'do_package' and 
their subordinate tasks.

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.

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