Bringing an image from OE to OE-Core

Bringing an image from OE to OE-Core

[Philip Balister]

I'm about to start bringing some images I use from OE to OE-core. The 
first issue I saw is there is no task-proper-tools in oe-core (where 
oe-core means the set of layers created by the Angstrom setup scripts).

Should I add task-proper-tools to meta-oe, or is there a better way to 
add a full features set of tools to an image? Basically, the image is 
more desktop like than embedded.

Philip

Re: Bringing an image from OE to OE-Core

[Saul Wold]

On 10/04/2011 12:58 PM, Philip Balister wrote:
> I'm about to start bringing some images I use from OE to OE-core. The
> first issue I saw is there is no task-proper-tools in oe-core (where
> oe-core means the set of layers created by the Angstrom setup scripts).
>
Philip,

Have you looked at task-core-basic, it is supposed to be more of a 
desktop like set of tools, the idea being it's heavier weight than core, 
will move to supporting the non-graphical part of LSB.

Another caveat for task-core-basic is that it's the largetest non-gplv3 
task that is used by core-image-basic.

Does this task approach what you are looking for?

Sau!


> Should I add task-proper-tools to meta-oe, or is there a better way to
> add a full features set of tools to an image? Basically, the image is
> more desktop like than embedded.
>
> Philip
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: Bringing an image from OE to OE-Core

[Khem Raj]

On Tue, Oct 4, 2011 at 12:58 PM, Philip Balister <philip@balister.org> wrote:
> I'm about to start bringing some images I use from OE to OE-core. The first
> issue I saw is there is no task-proper-tools in oe-core (where oe-core means
> the set of layers created by the Angstrom setup scripts).
>
> Should I add task-proper-tools to meta-oe, or is there a better way to add a
> full features set of tools to an image? Basically, the image is more desktop
> like than embedded.

there are meta stuff like tools-debug, tools-sdk in oe-core. See if
you can use them
to construct your image. If it seems a common enough subset that can be used in
multiple images then you could add the task to meta-oe like we have
for task-cli-tools
but a good judgment would be appropriate.

>
> Philip
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: Bringing an image from OE to OE-Core

[Philip Balister]

On 10/04/2011 04:08 PM, Saul Wold wrote:
> On 10/04/2011 12:58 PM, Philip Balister wrote:
>> I'm about to start bringing some images I use from OE to OE-core. The
>> first issue I saw is there is no task-proper-tools in oe-core (where
>> oe-core means the set of layers created by the Angstrom setup scripts).
>>
> Philip,
>
> Have you looked at task-core-basic, it is supposed to be more of a
> desktop like set of tools, the idea being it's heavier weight than core,
> will move to supporting the non-graphical part of LSB.
>
> Another caveat for task-core-basic is that it's the largetest non-gplv3
> task that is used by core-image-basic.
>
> Does this task approach what you are looking for?

It looks like a start, but I notice it brings in rpm. I'm not sure if I 
want that. I would have thought that the package manager would be a 
distro decision.

Philip


>
> Sau!
>
>
>> Should I add task-proper-tools to meta-oe, or is there a better way to
>> add a full features set of tools to an image? Basically, the image is
>> more desktop like than embedded.
>>
>> Philip
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>

Re: Bringing an image from OE to OE-Core

[Richard Purdie]

On Tue, 2011-10-04 at 15:58 -0400, Philip Balister wrote:
> I'm about to start bringing some images I use from OE to OE-core. The 
> first issue I saw is there is no task-proper-tools in oe-core (where 
> oe-core means the set of layers created by the Angstrom setup scripts).
> 
> Should I add task-proper-tools to meta-oe, or is there a better way to 
> add a full features set of tools to an image? Basically, the image is 
> more desktop like than embedded.

The core-image-lsb is the OE-Core image with the full fat tools
included. I'd suggest starting from that and see what is missing.

I'd also note we have IMAGE_FEATURES which you can add tools-sdk to
which may or may not include more of what you want (basically a
development toolchain+tools).

CHeers,

Richard

Re: Bringing an image from OE to OE-Core

[Saul Wold]

On 10/04/2011 01:27 PM, Philip Balister wrote:
> On 10/04/2011 04:08 PM, Saul Wold wrote:
>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>> I'm about to start bringing some images I use from OE to OE-core. The
>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>
>> Philip,
>>
>> Have you looked at task-core-basic, it is supposed to be more of a
>> desktop like set of tools, the idea being it's heavier weight than core,
>> will move to supporting the non-graphical part of LSB.
>>
>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>> task that is used by core-image-basic.
>>
>> Does this task approach what you are looking for?
>
> It looks like a start, but I notice it brings in rpm. I'm not sure if I
> want that. I would have thought that the package manager would be a
> distro decision.
>
That's a bug that I would certainly take a patch for, unless rpm is 
required as part of LSB, that will need to be verified.

Sau!

> Philip
>
>
>>
>> Sau!
>>
>>
>>> Should I add task-proper-tools to meta-oe, or is there a better way to
>>> add a full features set of tools to an image? Basically, the image is
>>> more desktop like than embedded.
>>>
>>> Philip
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: Bringing an image from OE to OE-Core

[Mark Hatle]

On 10/4/11 3:32 PM, Saul Wold wrote:
> On 10/04/2011 01:27 PM, Philip Balister wrote:
>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>
>>> Philip,
>>>
>>> Have you looked at task-core-basic, it is supposed to be more of a
>>> desktop like set of tools, the idea being it's heavier weight than core,
>>> will move to supporting the non-graphical part of LSB.
>>>
>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>> task that is used by core-image-basic.
>>>
>>> Does this task approach what you are looking for?
>>
>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>> want that. I would have thought that the package manager would be a
>> distro decision.
>>
> That's a bug that I would certainly take a patch for, unless rpm is 
> required as part of LSB, that will need to be verified.

The ability to install RPM packages is required by the LSB.  The LSB does not
require RPM however.  (yes I know, odd requirement, but with things like alien
it's doable on debian systems.)

But yes, RPM is included to satisfy that requirement.

--Mark

> Sau!
> 
>> Philip
>>
>>
>>>
>>> Sau!
>>>
>>>
>>>> Should I add task-proper-tools to meta-oe, or is there a better way to
>>>> add a full features set of tools to an image? Basically, the image is
>>>> more desktop like than embedded.
>>>>
>>>> Philip
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Bringing an image from OE to OE-Core

[Philip Balister]

On 10/04/2011 06:43 PM, Mark Hatle wrote:
> On 10/4/11 3:32 PM, Saul Wold wrote:
>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>
>>>> Philip,
>>>>
>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>> will move to supporting the non-graphical part of LSB.
>>>>
>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>> task that is used by core-image-basic.
>>>>
>>>> Does this task approach what you are looking for?
>>>
>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>> want that. I would have thought that the package manager would be a
>>> distro decision.
>>>
>> That's a bug that I would certainly take a patch for, unless rpm is
>> required as part of LSB, that will need to be verified.
>
> The ability to install RPM packages is required by the LSB.  The LSB does not
> require RPM however.  (yes I know, odd requirement, but with things like alien
> it's doable on debian systems.)
>
> But yes, RPM is included to satisfy that requirement.

This is beginning to look like a trickier problem than I would like. 
Between oe-core and meta-angstrom, there are a number of tasks/images to 
start from, but they each have something I don't like:

1) I do not want rpm in the image. This would confuse my customer base.
2) I am tired of dropbear, I want openssh only.
3) I need the full versions of tools, not the busybox ones.
4) I am not limited to gpv2 software.

Richard, it looks to me like we should add an item for the next Yocto 
development cycle to review how images are built and try to make the 
base stuff in oe-core more usable by everyone. We need to define what 
choices are made by distros. For example opkg, rpm, no package 
management in image. Images may want dropbear or openssh.

Short term, I think I'll copy the tasks/images into my bsp and get some 
stuff together for testing. I'd like a better long term solution though.

Philip

Re: Bringing an image from OE to OE-Core

[Eric Bénard]

Hi Philip,

Le 05/10/2011 16:14, Philip Balister a écrit :
> Short term, I think I'll copy the tasks/images into my bsp and get some
> stuff together for testing. I'd like a better long term solution though.
>
that's what we also did here to get the wanted result without using "standard"
variables which bring too much things in the image.

Eric

Re: Bringing an image from OE to OE-Core

[Mark Hatle]

On 10/5/11 9:14 AM, Philip Balister wrote:
> On 10/04/2011 06:43 PM, Mark Hatle wrote:
>> On 10/4/11 3:32 PM, Saul Wold wrote:
>>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>>
>>>>> Philip,
>>>>>
>>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>>> will move to supporting the non-graphical part of LSB.
>>>>>
>>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>>> task that is used by core-image-basic.
>>>>>
>>>>> Does this task approach what you are looking for?
>>>>
>>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>>> want that. I would have thought that the package manager would be a
>>>> distro decision.
>>>>
>>> That's a bug that I would certainly take a patch for, unless rpm is
>>> required as part of LSB, that will need to be verified.
>>
>> The ability to install RPM packages is required by the LSB.  The LSB does not
>> require RPM however.  (yes I know, odd requirement, but with things like alien
>> it's doable on debian systems.)
>>
>> But yes, RPM is included to satisfy that requirement.
> 
> This is beginning to look like a trickier problem than I would like. 
> Between oe-core and meta-angstrom, there are a number of tasks/images to 
> start from, but they each have something I don't like:
> 
> 1) I do not want rpm in the image. This would confuse my customer base.
> 2) I am tired of dropbear, I want openssh only.
> 3) I need the full versions of tools, not the busybox ones.
> 4) I am not limited to gpv2 software.
> 
> Richard, it looks to me like we should add an item for the next Yocto 
> development cycle to review how images are built and try to make the 
> base stuff in oe-core more usable by everyone. We need to define what 
> choices are made by distros. For example opkg, rpm, no package 
> management in image. Images may want dropbear or openssh.
> 
> Short term, I think I'll copy the tasks/images into my bsp and get some 
> stuff together for testing. I'd like a better long term solution though.

I'd suggest for now you try "hob".  It's capable of setting up image classes
that can do exactly what you want.. selecting specific packages that must be on
the target image and generating it.

I think the key thing for oe-core is that we'll never have the "right" set of
predefined images.. but we do need something so we can run the specific suite of
tests to show that things are function, as well as give starting points.

And I absolutely agree that we need to re-evaluate the configurations and come
up with distribution flags (feature flags?) that can do things like
enable/disable busybox, dropbear and other tooling.  (GPLv2 packages are only
built if you've excluded GPLv3 from your build.. otherwise the latest/greatest
version is defaulted to on.)

--Mark

> Philip

Re: Bringing an image from OE to OE-Core

[Koen Kooi]

Op 5 okt. 2011 om 09:14 heeft Philip Balister <philip@balister.org> het volgende geschreven:

> On 10/04/2011 06:43 PM, Mark Hatle wrote:
>> On 10/4/11 3:32 PM, Saul Wold wrote:
>>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>> 
>>>>> Philip,
>>>>> 
>>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>>> will move to supporting the non-graphical part of LSB.
>>>>> 
>>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>>> task that is used by core-image-basic.
>>>>> 
>>>>> Does this task approach what you are looking for?
>>>> 
>>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>>> want that. I would have thought that the package manager would be a
>>>> distro decision.
>>>> 
>>> That's a bug that I would certainly take a patch for, unless rpm is
>>> required as part of LSB, that will need to be verified.
>> 
>> The ability to install RPM packages is required by the LSB.  The LSB does not
>> require RPM however.  (yes I know, odd requirement, but with things like alien
>> it's doable on debian systems.)
>> 
>> But yes, RPM is included to satisfy that requirement.
> 
> This is beginning to look like a trickier problem than I would like. Between oe-core and meta-angstrom, there are a number of tasks/images to start from, but they each have something I don't like:
> 
> 1) I do not want rpm in the image. This would confuse my customer base.
> 2) I am tired of dropbear, I want openssh only.

fwiw 0.53 fixed most of my problems (e.g x11 forwarding), does it fix your issues as well?





> 3) I need the full versions of tools, not the busybox ones.
> 4) I am not limited to gpv2 software.
> 
> Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh.
> 
> Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though.
> 
> Philip
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Bringing an image from OE to OE-Core

[Eric Bénard]

Hi Philip,

Le 05/10/2011 16:14, Philip Balister a écrit :
> Short term, I think I'll copy the tasks/images into my bsp and get some
> stuff together for testing. I'd like a better long term solution though.
>
that's what we also did here to get the wanted result without using "standard"
variables which bring too much things in the image.

Eric

Re: Bringing an image from OE to OE-Core

[Khem Raj]

On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister <philip@balister.org> wrote:
>
> 1) I do not want rpm in the image. This would confuse my customer base.
> 2) I am tired of dropbear, I want openssh only.
> 3) I need the full versions of tools, not the busybox ones.
> 4) I am not limited to gpv2 software.
>
> Richard, it looks to me like we should add an item for the next Yocto
> development cycle to review how images are built and try to make the base
> stuff in oe-core more usable by everyone. We need to define what choices are
> made by distros. For example opkg, rpm, no package management in image.
> Images may want dropbear or openssh.
>
> Short term, I think I'll copy the tasks/images into my bsp and get some
> stuff together for testing. I'd like a better long term solution though.

There always will be customizations needed. But we can strive for
better basic blocks

Re: Bringing an image from OE to OE-Core

[Philip Balister]

On 10/05/2011 03:35 PM, Khem Raj wrote:
> On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<philip@balister.org>  wrote:
>>
>> 1) I do not want rpm in the image. This would confuse my customer base.
>> 2) I am tired of dropbear, I want openssh only.
>> 3) I need the full versions of tools, not the busybox ones.
>> 4) I am not limited to gpv2 software.
>>
>> Richard, it looks to me like we should add an item for the next Yocto
>> development cycle to review how images are built and try to make the base
>> stuff in oe-core more usable by everyone. We need to define what choices are
>> made by distros. For example opkg, rpm, no package management in image.
>> Images may want dropbear or openssh.
>>
>> Short term, I think I'll copy the tasks/images into my bsp and get some
>> stuff together for testing. I'd like a better long term solution though.
>
> There always will be customizations needed. But we can strive for
> better basic blocks

Sure. The immediate things I noticed are rpm being installed and lack of 
a way to chose between dropbear/openssh.

I think it is worth having a conversation to find out if when can make 
it easier for users to create images, with a small number of knobs to turn.

Philip

Re: Bringing an image from OE to OE-Core

[Joshua Lock]

On Wed, 2011-10-05 at 16:03 -0400, Philip Balister wrote:
> On 10/05/2011 03:35 PM, Khem Raj wrote:
> > On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<philip@balister.org>  wrote:
> >>
> >> 1) I do not want rpm in the image. This would confuse my customer base.
> >> 2) I am tired of dropbear, I want openssh only.
> >> 3) I need the full versions of tools, not the busybox ones.
> >> 4) I am not limited to gpv2 software.
> >>
> >> Richard, it looks to me like we should add an item for the next Yocto
> >> development cycle to review how images are built and try to make the base
> >> stuff in oe-core more usable by everyone. We need to define what choices are
> >> made by distros. For example opkg, rpm, no package management in image.
> >> Images may want dropbear or openssh.
> >>
> >> Short term, I think I'll copy the tasks/images into my bsp and get some
> >> stuff together for testing. I'd like a better long term solution though.
> >
> > There always will be customizations needed. But we can strive for
> > better basic blocks
> 
> Sure. The immediate things I noticed are rpm being installed and lack of 
> a way to chose between dropbear/openssh.

Core images automatically include the correct package manager when the
image feature package-management is defined for the image.

It would be nice to define a variable/feature to control SSH server.

Regards,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Bringing an image from OE to OE-Core

[Khem Raj]

On Wed, Oct 5, 2011 at 1:18 PM, Joshua Lock <josh@linux.intel.com> wrote:
> Core images automatically include the correct package manager when the
> image feature package-management is defined for the image.
>
> It would be nice to define a variable/feature to control SSH server.
>

virtual providers could help here.

Re: Bringing an image from OE to OE-Core

[Philip Balister]

On 10/05/2011 12:20 PM, Koen Kooi wrote:
>
>
> Op 5 okt. 2011 om 09:14 heeft Philip Balister<philip@balister.org>  het volgende geschreven:
>
>> On 10/04/2011 06:43 PM, Mark Hatle wrote:
>>> On 10/4/11 3:32 PM, Saul Wold wrote:
>>>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>>>
>>>>>> Philip,
>>>>>>
>>>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>>>> will move to supporting the non-graphical part of LSB.
>>>>>>
>>>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>>>> task that is used by core-image-basic.
>>>>>>
>>>>>> Does this task approach what you are looking for?
>>>>>
>>>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>>>> want that. I would have thought that the package manager would be a
>>>>> distro decision.
>>>>>
>>>> That's a bug that I would certainly take a patch for, unless rpm is
>>>> required as part of LSB, that will need to be verified.
>>>
>>> The ability to install RPM packages is required by the LSB.  The LSB does not
>>> require RPM however.  (yes I know, odd requirement, but with things like alien
>>> it's doable on debian systems.)
>>>
>>> But yes, RPM is included to satisfy that requirement.
>>
>> This is beginning to look like a trickier problem than I would like. Between oe-core and meta-angstrom, there are a number of tasks/images to start from, but they each have something I don't like:
>>
>> 1) I do not want rpm in the image. This would confuse my customer base.
>> 2) I am tired of dropbear, I want openssh only.
>
> fwiw 0.53 fixed most of my problems (e.g x11 forwarding), does it fix your issues as well?

It is more that users know openssh and sometimes have issues with 
dropbear. And image size is not an issue.

Philip

Re: Bringing an image from OE to OE-Core

[Saul Wold]

On 10/05/2011 01:03 PM, Philip Balister wrote:
> On 10/05/2011 03:35 PM, Khem Raj wrote:
>> On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<philip@balister.org>
>> wrote:
>>>
>>> 1) I do not want rpm in the image. This would confuse my customer base.
>>> 2) I am tired of dropbear, I want openssh only.
>>> 3) I need the full versions of tools, not the busybox ones.
>>> 4) I am not limited to gpv2 software.
>>>
>>> Richard, it looks to me like we should add an item for the next Yocto
>>> development cycle to review how images are built and try to make the
>>> base
>>> stuff in oe-core more usable by everyone. We need to define what
>>> choices are
>>> made by distros. For example opkg, rpm, no package management in image.
>>> Images may want dropbear or openssh.
>>>
>>> Short term, I think I'll copy the tasks/images into my bsp and get some
>>> stuff together for testing. I'd like a better long term solution though.
>>
>> There always will be customizations needed. But we can strive for
>> better basic blocks
>
> Sure. The immediate things I noticed are rpm being installed and lack of
> a way to chose between dropbear/openssh.
>
> I think it is worth having a conversation to find out if when can make
> it easier for users to create images, with a small number of knobs to turn.
>
I agree, your 4 items above make sense and we could create a set of 
tasks that can be use it as building blocks, I think that 
task-core-basic could be a starting point for that.

We did work to enable the selection of either openssh/dropbear but at an 
IMAGE_FEATURE level, not as a DISTRO_FEATURE or virtual.

Let's see what you come up with for your tasks and we can go from there.

Thanks
Sau!

> Philip
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: Bringing an image from OE to OE-Core

[Frans Meulenbroeks]

[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]

2011/10/6 Saul Wold <saul.wold@intel.com>

> On 10/05/2011 01:03 PM, Philip Balister wrote:
>
>> On 10/05/2011 03:35 PM, Khem Raj wrote:
>>
>>> On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<philip@balister.org>
>>> wrote:
>>>
>>>>
>>>> 1) I do not want rpm in the image. This would confuse my customer base.
>>>> 2) I am tired of dropbear, I want openssh only.
>>>> 3) I need the full versions of tools, not the busybox ones.
>>>> 4) I am not limited to gpv2 software.
>>>>
>>>> Richard, it looks to me like we should add an item for the next Yocto
>>>> development cycle to review how images are built and try to make the
>>>> base
>>>> stuff in oe-core more usable by everyone. We need to define what
>>>> choices are
>>>> made by distros. For example opkg, rpm, no package management in image.
>>>> Images may want dropbear or openssh.
>>>>
>>>> Short term, I think I'll copy the tasks/images into my bsp and get some
>>>> stuff together for testing. I'd like a better long term solution though.
>>>>
>>>
>>> There always will be customizations needed. But we can strive for
>>> better basic blocks
>>>
>>
>> Sure. The immediate things I noticed are rpm being installed and lack of
>> a way to chose between dropbear/openssh.
>>
>> I think it is worth having a conversation to find out if when can make
>> it easier for users to create images, with a small number of knobs to
>> turn.
>>
>>  I agree, your 4 items above make sense and we could create a set of tasks
> that can be use it as building blocks, I think that task-core-basic could be
> a starting point for that.
>
> We did work to enable the selection of either openssh/dropbear but at an
> IMAGE_FEATURE level, not as a DISTRO_FEATURE or virtual.
>
> Let's see what you come up with for your tasks and we can go from there.
>
> Thanks
> Sau!
>
> The usability of tasks in general greatly depends on the use case you are
in.
To give an idea of our use case.
We make embedded systems to which the user only can interact in a specified
way. No online upgrading of packages let alone installing new ones (actually
some of the boards do not even have a network interface).
As we are limited on flash space our images are hand crafted, only to
contain those packages that we really need.
Wrt kernel: we hardly use modules, almost everything is configured into the
kernel (as we exactly know our hardware).

Then again if you have more space and or need to be more flexible tasks
definitely can have their merits. (especially when mapping machine features
to kernel modules etc).

For the specific case with dropbear.
OE classic task-base.bb contained
DISTRO_SSH_DAEMON ?= "dropbear"
and then used the variable in the image list
OE classic task-poky.bb hardcoded dropbear.

Personally I don't really see too much value in having the package in a var.
It is more work to type ${DISTRO_SSH_DAEMON} in the IMAGE-INSTALL than it is
to type dropbear or openssh.

Frans

[-- Attachment #2: Type: text/html, Size: 3821 bytes --]