Re: [PATCH v3] meta/classes: generate bill of material from image

[Claudius Heine <claudius.heine.ext@siemens.com>]

On 12/08/2019 11.09, Quirin Gylstorff wrote:
> 
> 
> On 8/12/19 10:04 AM, Claudius Heine wrote:
>> Hi Quirin,
>>
>> On 09/08/2019 12.30, [ext] Q. Gylstorff wrote:
>>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
>>>
>>> To create products it is necessary to have a list
>>> of used packages for clearance and to security monitoring.
>>> To get a simple list of packages use dpkg-query and generate
>>> a list with the following pattern:
>>>
>>> source name| source version | binary package name | binary version
>>>
>>> The list is stored in ${IMAGE_FULLNAME}.rootfs.manifest
>>>
>>> Remove the feature with:
>>> ROOTFS_FEATURES_remove = "generate-manifest"
>>>
>>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
>>> ---
>>> Changes:
>>> v3:
>>> Add list of manifest for buildchroot manifest
>>> This list can be exdent to add additional output generators
>>> v2:
>>> use FEATURE instead of own variable
>>>
>>> .../image-package-list-extension.bbclass      | 66 +++++++++++++++++++
>>>   meta/classes/image.bbclass                    |  3 +-
>>>   2 files changed, 68 insertions(+), 1 deletion(-)
>>>   create mode 100644 meta/classes/image-package-list-extension.bbclass
>>>
>>> diff --git a/meta/classes/image-package-list-extension.bbclass 
>>> b/meta/classes/image-package-list-extension.bbclass
>>> new file mode 100644
>>> index 0000000..11896f1
>>> --- /dev/null
>>> +++ b/meta/classes/image-package-list-extension.bbclass
>>> @@ -0,0 +1,66 @@
>>> +# This software is a part of ISAR.
>>> +# Copyright (C) Siemens AG, 2019
>>> +#
>>> +# SPDX-License-Identifier: MIT
>>> +
>>> +MANIFESTS ?= "target build"
>>> +MANIFEST_build[rootfs] ?= "/var/lib/dpkg"
>>> +MANIFEST_target[rootfs] ?= "${PP_ROOTFS}/var/lib/dpkg"
>>
>> Have you planned additional flags for this?
>>
>> Currently I think that this mechanism is a bit of an overkill for just 
>> two variables. But since you touched this now and are the second users 
>> of this, I have further comments ;).
>>
> 
> One Idea was to add use this to add additional generators. If this is 
> not a use case anymore than it is overkill.

 From my perspective, having multiple manifest generators in upstream is 
not a use-case anyway. I would like just one that covers most of the 
common use-cases. What those 'common use-cases' are should probably be 
documented somewhere. If CSV fits the bill of those, then I am fine with it.

I just suggested JSON because that might be easier to integrate with 
tools I am used to. But I am probably not the person using the manifest 
information anyway.

The problem with arguing about the output format is probably that there 
is no clear listing of all the use-cases. For instance Gernots remark 
that the manifest should be directly importable in Excel was new to me, 
but makes sense. I just thought before that the manifest file is further 
processed by scripts to generate some human readable documents or 
integrate it into a web app or database. In those cases a structured 
text serialization format might have been better.

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