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

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

Am Mon, 4 Sep 2017 19:30:43 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> 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 <henning.schild@siemens.com>
> >>> ---
> >>>    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
>