From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6721684426774806528 X-Received: by 2002:a05:6000:12c5:: with SMTP id l5mr27275349wrx.122.1565603846023; Mon, 12 Aug 2019 02:57:26 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:6942:: with SMTP id r2ls1387153wrw.3.gmail; Mon, 12 Aug 2019 02:57:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwoshs6oSMEgo5BT5SnnESgM2cTTaBg/f+8SyQl3skwpeQdwQsEbHeN5ui/Gj8ZfJpJ2vk+ X-Received: by 2002:a5d:4d4c:: with SMTP id a12mr30533155wru.343.1565603845605; Mon, 12 Aug 2019 02:57:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565603845; cv=none; d=google.com; s=arc-20160816; b=qKhRCXJNmmljswH+GesqDO3Ls2bILNt4CCbehFd3rWNQskfuzRLCYnoVxelQFMfdWJ Gan3rOIlfXmw7DDN6LbpV/Eyte0v0/DX8G7VCp83y8uh9B0DA7ZW5w9TABzUlkb0H3Km iwvvaD2Ey16LISKriuELf8XEBnHcYZrKOif5N7v+u2fPlKNQFWZVNp+nH2FqGcRAv5Bs 6lrUl2VcAA9azVzuY+AJBbQXWIEFQfxHUZlLJNIw7nYd6ZolB5scIkgnEWC9jaOZK+Jf js0cdshUHmX9myON/iVPkTpyf697SCBHpy+AYm4aZFHjZe3SClcji6/T4d3TqaKpxsEl buGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=/QbhO3f02n3oUz5n613YrhXTd0k7VfmU8Fx0N13sjsA=; b=TJTPxZ/W7YMlT85N5wbp1NDVFqdblztMawPDcr75y+DuurygLtYz3u7ed5efGl8Giq zg/3xaUXGuLKDKzurnVQSildl4GJ1SzghEhbDAcQNCVAi75uHjE9aUpjqNKs3cSTX+x6 SZT9kb72YYSTReaFuLA+v7S/mlHxof204ITZua+xO1W994Jv/9ruZUeAx2sfZUmF1B8H TyL03UochAR/JLrxrjFSGpeklzBM5XVCzQzVfs3aI2aRcxYWGa+ZlmHAb3nMnwI3eQJA Nk6lhqvo1uw3Y5d/B3Z+N4/syBgIGsmZH4QjTv8SS4OG38NMEYZK+a20uLpdoqWSfOkA 2f8g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id p67si149169wme.2.2019.08.12.02.57.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 02:57:25 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x7C9vPIu005448 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Aug 2019 11:57:25 +0200 Received: from [139.25.69.208] (linux-ses-ext02.ppmd.siemens.net [139.25.69.208]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x7C9vP7J030723; Mon, 12 Aug 2019 11:57:25 +0200 Subject: Re: [PATCH v3] meta/classes: generate bill of material from image To: Quirin Gylstorff , isar-users@googlegroups.com References: <2c58eae5-4d77-776f-3d4e-5fda95dc27d5@siemens.com> <20190809103046.10493-1-Quirin.Gylstorff@siemens.com> <8c27aed7-56b7-89f8-f84d-093334627dae@siemens.com> <3221bfdb-641b-7e54-3fb5-1facbf6e5585@siemens.com> From: Claudius Heine Message-ID: <298c42ee-7882-6406-b4c1-a7a80ac9ab11@siemens.com> Date: Mon, 12 Aug 2019 11:57:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <3221bfdb-641b-7e54-3fb5-1facbf6e5585@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: Sqs+gtMZTOGQ 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 >>> >>> 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 >>> --- >>> 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