[PATCH 0/1] Produce an image manifest

[PATCH 0/1] Produce an image manifest

[Cedric_Hombourger]

From: Cedric Hombourger <Cedric_Hombourger@mentor.com>

Mimic the OpenEmbedded/Yocto project and produce an image manifest along the
actual binary image. The manifest include some package-level details such as
the architecture, version, and, when specified, the source package it was
built from.

Cedric Hombourger (1):
  image: create an image manifest listing installed packages

 meta/classes/image.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

-- 
2.11.0

[PATCH 1/1] image: create an image manifest listing installed packages

[Cedric_Hombourger]

From: Cedric Hombourger <Cedric_Hombourger@mentor.com>

Produce an image manifest that lists all packages installed into the
image. Note the architecture, version and (when specified) the source
package. The package details are tab-separated and may easily be
imported into a spreadsheet (e.g. should you need to provide a Bill
Of Material).

Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
---
 meta/classes/image.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 2c2bafc..c7aa698 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -84,6 +84,16 @@ do_populate() {
 addtask populate before do_build after do_unpack
 do_populate[deptask] = "do_deploy_deb"
 
+# Create a manifest of installed packages and their versions
+do_manifest() {
+    install -m 755 -d ${DEPLOY_DIR_IMAGE}
+    sudo chroot ${IMAGE_ROOTFS} dpkg-query \
+        -W -f '${Package}\t${Architecture}\t${Version}\t${Source}\n' \
+        >${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.manifest
+}
+
+addtask manifest before do_build after do_populate
+
 do_copy_boot_files() {
     KERNEL_IMAGE=${@get_image_name(d, 'vmlinuz')}
     if [ -n "${KERNEL_IMAGE}" ]; then
-- 
2.11.0

Re: [PATCH 1/1] image: create an image manifest listing installed packages

[Jan Kiszka]

On 2018-02-05 14:30, Cedric_Hombourger@mentor.com wrote:
> From: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> 
> Produce an image manifest that lists all packages installed into the
> image. Note the architecture, version and (when specified) the source
> package. The package details are tab-separated and may easily be
> imported into a spreadsheet (e.g. should you need to provide a Bill
> Of Material).
> 
> Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> ---
>  meta/classes/image.bbclass | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 2c2bafc..c7aa698 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -84,6 +84,16 @@ do_populate() {
>  addtask populate before do_build after do_unpack
>  do_populate[deptask] = "do_deploy_deb"
>  
> +# Create a manifest of installed packages and their versions
> +do_manifest() {
> +    install -m 755 -d ${DEPLOY_DIR_IMAGE}
> +    sudo chroot ${IMAGE_ROOTFS} dpkg-query \
> +        -W -f '${Package}\t${Architecture}\t${Version}\t${Source}\n' \
> +        >${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.manifest
> +}
> +
> +addtask manifest before do_build after do_populate
> +

Makes sense. But we should also include the hash of the repo that
initiated the build. We do this in several of out Yocto projects to
resolve the usual question: "Am I really running the latest version?"

The key problem, though, is to establish a way to define the top-level
layer and, thus, the repo we are interested in. For the yocto cases, we
hard-coded that into the product layers, but there are surely better
approaches.

>  do_copy_boot_files() {
>      KERNEL_IMAGE=${@get_image_name(d, 'vmlinuz')}
>      if [ -n "${KERNEL_IMAGE}" ]; then
> 

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 1/1] image: create an image manifest listing installed packages

[chombourger]

[-- Attachment #1.1: Type: text/plain, Size: 2371 bytes --]

Hi Jan,

Yes I agree that we should "version" the artifacts we produce but this 
should be done for all of them starting with the image binary itself.
IMO - this would warrant another patchset / topic

Cedric

On Monday, February 5, 2018 at 2:38:57 PM UTC+1, Jan Kiszka wrote:
>
> On 2018-02-05 14:30, Cedric_H...@mentor.com <javascript:> wrote: 
> > From: Cedric Hombourger <Cedric_H...@mentor.com <javascript:>> 
> > 
> > Produce an image manifest that lists all packages installed into the 
> > image. Note the architecture, version and (when specified) the source 
> > package. The package details are tab-separated and may easily be 
> > imported into a spreadsheet (e.g. should you need to provide a Bill 
> > Of Material). 
> > 
> > Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com <javascript:>> 
> > --- 
> >  meta/classes/image.bbclass | 10 ++++++++++ 
> >  1 file changed, 10 insertions(+) 
> > 
> > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass 
> > index 2c2bafc..c7aa698 100644 
> > --- a/meta/classes/image.bbclass 
> > +++ b/meta/classes/image.bbclass 
> > @@ -84,6 +84,16 @@ do_populate() { 
> >  addtask populate before do_build after do_unpack 
> >  do_populate[deptask] = "do_deploy_deb" 
> >   
> > +# Create a manifest of installed packages and their versions 
> > +do_manifest() { 
> > +    install -m 755 -d ${DEPLOY_DIR_IMAGE} 
> > +    sudo chroot ${IMAGE_ROOTFS} dpkg-query \ 
> > +        -W -f '${Package}\t${Architecture}\t${Version}\t${Source}\n' \ 
> > +        >${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.manifest 
> > +} 
> > + 
> > +addtask manifest before do_build after do_populate 
> > + 
>
> Makes sense. But we should also include the hash of the repo that 
> initiated the build. We do this in several of out Yocto projects to 
> resolve the usual question: "Am I really running the latest version?" 
>
> The key problem, though, is to establish a way to define the top-level 
> layer and, thus, the repo we are interested in. For the yocto cases, we 
> hard-coded that into the product layers, but there are surely better 
> approaches. 
>
> >  do_copy_boot_files() { 
> >      KERNEL_IMAGE=${@get_image_name(d, 'vmlinuz')} 
> >      if [ -n "${KERNEL_IMAGE}" ]; then 
> > 
>
> Jan 
>
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE 
> Corporate Competence Center Embedded Linux 
>

[-- Attachment #1.2: Type: text/html, Size: 3452 bytes --]