Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: Joshua Lock <joshua.g.lock@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 00/10] Integrate swupd software updater
Date: Wed, 24 Feb 2016 16:37:55 +0100	[thread overview]
Message-ID: <1456328275.30039.49.camel@intel.com> (raw)
In-Reply-To: <cover.1456325292.git.joshua.g.lock@intel.com>

Hello!

I haven't had a chance to play with the actual code yet and I don't know
yet when I'll be able to. Let me ask for some clarifications about the
approach first anyway.

On Wed, 2016-02-24 at 14:52 +0000, Joshua Lock wrote:
> Approach:
> An image that inherits the swupd-image bbclass will automatically have bundle
> 'chroots' created which contain the filesystem contents of the specified
> bundles, with the contents of the inheriting image forming the default os-core
> bundle.
> 
> The mechanism to achieve this is that several virtual image recipes are created
> using the swupdbundle class, one for each defined bundle plus a 'mega' image
> recipe. The 'mega' image contains the base image plus the contents of all of the
> bundles, whilst bundle images contain only the base image plus the contents of a
> single bundle.

Just to be sure, the actual "content" (a term that is a bit too
overloaded to be used precisely in all cases) of a file and its meta
attributes will come from the mega image, and the virtual image recipes,
including the base image, are merely used to generate file lists?

What is the content of the actual image that gets created? It has to
match the content (= file content and meta information) of the mega
image and not of the base image, otherwise there can be inconsistencies
between the actual running image and the core os bundle. I suppose swupd
will be able to fix that, but I'm not sure.

It sounds like this bundle creation is completely separated from the
regular image creation; if so, then I suspect that this may have to
change.

> We took the approach of building images, rather than populating the chroot-like
> bundle directories with a package manager, because various layers and recipes
> make changes to the rootfs contents outside of the package manager, particularly
> with IMAGE_POSTPROCESS_COMMAND, etc.

Makes sense to me.

Have you considered generating the file lists more efficiently? I can
think of some alternatives, but all have downsides.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





  parent reply	other threads:[~2016-02-24 15:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24 14:52 [PATCH 00/10] Integrate swupd software updater Joshua Lock
2016-02-24 14:52 ` [PATCH 01/10] rsync: add native variant Joshua Lock
2016-02-24 14:52 ` [PATCH 02/10] swupd-server: initial recipe 2.53 Joshua Lock
2016-02-25  8:11   ` Maciej Borzecki
2016-02-25  8:51     ` Joshua G Lock
2016-02-24 14:52 ` [PATCH 03/10] hardlink: add new recipe Joshua Lock
2016-02-24 21:00   ` Burton, Ross
2016-02-24 22:57   ` Andre McCurdy
2016-02-25  8:48     ` Joshua G Lock
2016-02-25 17:13   ` Mark Hatle
2016-02-25 21:40     ` Joshua G Lock
2016-02-25 21:57       ` Mark Hatle
2016-02-24 14:52 ` [PATCH 04/10] swupd-client: Add recipe Joshua Lock
2016-02-25  8:07   ` Maciej Borzecki
2016-02-25  8:50     ` Joshua G Lock
2016-02-24 14:52 ` [PATCH 05/10] swupdbundle: new class to generate virtual images for swupd-image Joshua Lock
2016-02-25  8:19   ` Maciej Borzecki
2016-02-25  8:47     ` Joshua G Lock
2016-02-25 17:06   ` Patrick Ohly
2016-03-01 13:45     ` Joshua G Lock
2016-02-24 14:52 ` [PATCH 06/10] swupd-image.bbclass: initial class to support swupd updater Joshua Lock
2016-02-24 14:52 ` [PATCH 07/10] oe-swupd-helpers: provide swupd-client required helper scripts and units Joshua Lock
2016-02-24 14:52 ` [PATCH 08/10] swupd-client: RDEPENDS on oe-swupd-helpers Joshua Lock
2016-02-24 14:52 ` [PATCH 09/10] swupd-client: enable native builds Joshua Lock
2016-02-24 14:52 ` [PATCH 10/10] os-release: sanitise VERSION_ID field Joshua Lock
2016-02-24 15:37 ` Patrick Ohly [this message]
2016-02-24 16:14   ` [PATCH 00/10] Integrate swupd software updater Joshua G Lock
     [not found]   ` <1456330147.5333.14.camel@intel.com>
2016-02-24 18:49     ` Patrick Ohly
2016-03-01 16:18       ` Joshua G Lock
2016-02-24 16:06 ` Trevor Woerner
2016-02-24 16:35   ` Philip Balister
2016-02-24 18:36     ` Maciej Borzecki
2016-02-24 19:51     ` Paul Eggleton
2016-02-24 20:40       ` Philip Balister
2016-02-25 21:42         ` Joshua G Lock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1456328275.30039.49.camel@intel.com \
    --to=patrick.ohly@intel.com \
    --cc=joshua.g.lock@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox