Packaging and deploying multiple firmware image types in one

[Adriana Kobylak]

On 2019-11-14 01:51, Alexander A. Filippov wrote:
> On Tue, Nov 12, 2019 at 04:54:22PM -0600, Adriana Kobylak wrote:
>> 
>> Yeah, the purpose is not currently preserved across reboots. I have a 
>> change
>> here for that:
>> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-bmc-code-mgmt/+/27045
>> 
> 
> On Thu, Nov 14, 2019 at 03:14:41AM +0000, Adriana Kobylak (Code Review) 
> wrote:
>> ...
>> but let's continue on the mailing list about your thoughts on how you 
>> think
>> the tarball of tarballs should be handled.
>> 
> 
> Ok, here are my thoughts:
> The phosphor-version-software-manager might put all internal tarballs 
> in the
> /tmp/images folder during processing the top level tarball. That will 
> lead to
> creation of corresponding D-Bus objects. Each of them will have their 
> own
> purpose, version, object path and so on.

Yeah agree. We may still need some way to let the 
phosphor-version-software-manager
know that it needs to untar the internal tarballs, maybe a very simple 
MANIFEST
with a new field, then each individual tarball would have their own 
MANIFEST that
creates the D-Bus versions like you mentioned.

> 
> The root D-Bus object and their folder might be removed after that  to 
> reduce a
> used file system space.