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.zanu...@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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
