<br><br><div class="gmail_quote">2011/10/6 Saul Wold <span dir="ltr"><<a href="mailto:saul.wold@intel.com">saul.wold@intel.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 10/05/2011 01:03 PM, Philip Balister wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/05/2011 03:35 PM, Khem Raj wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<<a href="mailto:philip@balister.org" target="_blank">philip@balister.org</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1) I do not want rpm in the image. This would confuse my customer base.<br>
2) I am tired of dropbear, I want openssh only.<br>
3) I need the full versions of tools, not the busybox ones.<br>
4) I am not limited to gpv2 software.<br>
<br>
Richard, it looks to me like we should add an item for the next Yocto<br>
development cycle to review how images are built and try to make the<br>
base<br>
stuff in oe-core more usable by everyone. We need to define what<br>
choices are<br>
made by distros. For example opkg, rpm, no package management in image.<br>
Images may want dropbear or openssh.<br>
<br>
Short term, I think I'll copy the tasks/images into my bsp and get some<br>
stuff together for testing. I'd like a better long term solution though.<br>
</blockquote>
<br>
There always will be customizations needed. But we can strive for<br>
better basic blocks<br>
</blockquote>
<br>
Sure. The immediate things I noticed are rpm being installed and lack of<br>
a way to chose between dropbear/openssh.<br>
<br>
I think it is worth having a conversation to find out if when can make<br>
it easier for users to create images, with a small number of knobs to turn.<br>
<br>
</blockquote></div>
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.<br>
<br>
We did work to enable the selection of either openssh/dropbear but at an IMAGE_FEATURE level, not as a DISTRO_FEATURE or virtual.<br>
<br>
Let's see what you come up with for your tasks and we can go from there.<br>
<br>
Thanks<br>
Sau!<div><div></div><div class="h5"><br></div></div></blockquote></div>The usability of tasks in general greatly depends on the use case you are in.<br>To give an idea of our use case.<br>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).<br>
As we are limited on flash space our images are hand crafted, only to contain those packages that we really need.<br>Wrt kernel: we hardly use modules, almost everything is configured into the kernel (as we exactly know our hardware).<br>
<br>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).<br><br>For the specific case with dropbear.<br>
OE classic <a href="http://task-base.bb">task-base.bb</a> contained<br>DISTRO_SSH_DAEMON ?= "dropbear"<br>and then used the variable in the image list<br>OE classic <a href="http://task-poky.bb">task-poky.bb</a> hardcoded dropbear.<br>
<br>Personally I don't really see too much value in having the package in a var.<br>It is more work to type ${DISTRO_SSH_DAEMON} in the IMAGE-INSTALL than it is to type dropbear or openssh.<br><br>Frans<br>