Re: [PATCH 1/3] wic: Initial code for wic (OpenEmbedded Image Creator)

From: "David Nyström" <david.c.nystrom@gmail.com>
To: Tom Zanussi <tom.zanussi@linux.intel.com>,
	 Otavio Salvador <otavio@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/3] wic: Initial code for wic (OpenEmbedded Image Creator)
Date: Sat, 28 Sep 2013 14:17:38 +0200	[thread overview]
Message-ID: <5246C8E2.7060702@gmail.com> (raw)
In-Reply-To: <1380291699.31937.46.camel@empanada>

On 09/27/2013 04:21 PM, Tom Zanussi wrote:
> Hi Otavio,
>
> On Fri, 2013-09-27 at 11:01 -0300, Otavio Salvador wrote:
>> Hello Tom,
>>
>> On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
>> <tom.zanussi@linux.intel.com> wrote:
>>> Initial implementation of the 'wic' command.
>>>
><snip>
>> Could you please elaborate why to make a new command instead of using
>> the class system?
>>
>
> This isn't an either/or thing - the initial requirements were that the
> overall deployment effort end up being something that would be usable
> both from an external tool as well as from within the class system.

What do you mean when you say "within the class system" here ?
* A tool using only (kickstart for image cfg, partitioning et.c.) + 
(tmp/deploy/ipk|rpm|deb) as input data for image creation ?

Just my five cents,

I would like to see reproducible image creation from both the bitbake/OE 
build env and the nativesdk SDK build env.
This would require a common interface for input distribution data, It 
naturally feels like this interface should be the package repository.
i.e. if X is not packaged as class-target, it can't be included on the 
generated image.
Also, if X is required to generate the image, it should be packaged as 
class-nativesdk.

afaict, the standalone wic tool uses a hybrid approach, using 
OpenEmbedded build artifacts + a package repository as input for rootfs 
generation.
What is the long term plan for wic in regards to the above ?

Br,
David

> This just happens to be the initial (easier) part of that, the external
> tool, and I expect in 1.6 to be doing a lot of the harder part,
> integration with the build system.

> The most important part, I think, is that this provides a high-level
> user-oriented 'language' (the kickstart files) that users can use to
> define custom images, rather than having to muck around in class files
> or variable settings, or write specialized scripts such as mkefidisk.sh
> for example.
>
> Making that available from a standalone tool such as 'wic' is
> straightforward, doing the same from within the build system will
> require more thought and work, but that's what I'm hoping to do in
> 1.6...

>
> Tom
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>