2011/10/6 Saul Wold <saul.w...@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<phi...@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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
