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

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

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

> Hi agani, was a bit to fast sending the mail before,
> 
> On 08/31/2017 10:38 AM, [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.
> > 
> > Cheers,
> > Claudius
> >   
> >>
> >> 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() {  
> 
> OE has a slightly different naming scheme for these tasks. They would 
> call them 'do_package_deb_prepare' or similar [1]. Might cause
> confusion if we have different naming schemes between those two
> projects.

I have given up the naming discussions for now, especially comparison
to OE. These discsussions have held up important features for way too
long. I will probably accept any name chosen by others, unless it
contains implementation details and other things that do not belong
there.

> >> +    cat<<-__EOF__ > ${D}/DEBIAN/control
> >> +        Package: ${PN}
> >> +        Architecture: `dpkg --print-architecture`  
> 
> Are you sure that this works when cross building? Wouldn't dpkg print 
> the architecture of the host system instead of the target system? I 
> think this kind of information has to come from the machine variables.

Yes, will look into that.

Henning

> Cheers,
> Claudius
> 
> >> +        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 
> >   
> 
> [1] 
> http://git.openembedded.org/openembedded-core/tree/meta/classes/package_deb.bbclass#n43
>