static busybox?

static busybox?

[Stuart Yoder]

We are doing some work with LXC (containers) and one of the templates
is for busybox.  For LXC, the busybox package needs to be built statically and
there is a config option for this.

A couple possible approaches:

   -create a new 'busybox_static' recipe that the lxc package
    depends on that turns on the needed build options.   Pretty
    straightforward, but now there are 2 variants of the busybox
    package.

   -somehow propagate some configuration options through to
    the standard busybox recipe so it turns on the config
    option to build things statically.   Not sure how to
    do this, and seems like it could get pretty messy.

Any thoughts?

Thanks,
Stuart Yoder

Re: static busybox?

[McClintock Matthew-B29882]

On Tue, Jul 31, 2012 at 1:14 PM, Stuart Yoder <b08248@gmail.com> wrote:
> We are doing some work with LXC (containers) and one of the templates
> is for busybox.  For LXC, the busybox package needs to be built statically and
> there is a config option for this.
>
> A couple possible approaches:
>
>    -create a new 'busybox_static' recipe that the lxc package
>     depends on that turns on the needed build options.   Pretty
>     straightforward, but now there are 2 variants of the busybox
>     package.

This would seem to work OK with RDEPENDS += "busybox-static" and just
adding the extra static bits for for the static version. It seems OK
except we would/could start to get lots of recipes like this.

>    -somehow propagate some configuration options through to
>     the standard busybox recipe so it turns on the config
>     option to build things statically.   Not sure how to
>     do this, and seems like it could get pretty messy.

Are there any mechanism that currently exist for this? We could turn
on a DISTRO_FEATURE if we knew we were going use lxc, but that's more
involved than just adding the lxc recipe and getting the right stuff
in the root file system.

Does anyone else have any thoughts on the best approach here?

-M

Re: static busybox?

[Mark Hatle]

On 7/31/12 1:14 PM, Stuart Yoder wrote:
> We are doing some work with LXC (containers) and one of the templates
> is for busybox.  For LXC, the busybox package needs to be built statically and
> there is a config option for this.
>
> A couple possible approaches:
>
>     -create a new 'busybox_static' recipe that the lxc package
>      depends on that turns on the needed build options.   Pretty
>      straightforward, but now there are 2 variants of the busybox
>      package.
>
>     -somehow propagate some configuration options through to
>      the standard busybox recipe so it turns on the config
>      option to build things statically.   Not sure how to
>      do this, and seems like it could get pretty messy.
>
> Any thoughts?

We've been talking about this as well..  I'm currently of the opinion that the 
kernel's config fragement processing be added to busybox.  This way someone can 
simply add a configuration fragment via a bbappend, or other approach and it'll 
pick it up.   That same can be used to specify how to enable other optional 
pieces of busybox.

--Mark

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

Re: static busybox?

[Mark Hatle]

On 7/31/12 2:36 PM, McClintock Matthew-B29882 wrote:
> On Tue, Jul 31, 2012 at 1:14 PM, Stuart Yoder <b08248@gmail.com> wrote:
>> We are doing some work with LXC (containers) and one of the templates
>> is for busybox.  For LXC, the busybox package needs to be built statically and
>> there is a config option for this.
>>
>> A couple possible approaches:
>>
>>     -create a new 'busybox_static' recipe that the lxc package
>>      depends on that turns on the needed build options.   Pretty
>>      straightforward, but now there are 2 variants of the busybox
>>      package.
>
> This would seem to work OK with RDEPENDS += "busybox-static" and just
> adding the extra static bits for for the static version. It seems OK
> except we would/could start to get lots of recipes like this.
>
>>     -somehow propagate some configuration options through to
>>      the standard busybox recipe so it turns on the config
>>      option to build things statically.   Not sure how to
>>      do this, and seems like it could get pretty messy.
>
> Are there any mechanism that currently exist for this? We could turn
> on a DISTRO_FEATURE if we knew we were going use lxc, but that's more
> involved than just adding the lxc recipe and getting the right stuff
> in the root file system.

Kernel config fragment mechanism is there and IMHO works well for something like 
this, assuming configuration is using standard

FOO = value

# FOO is not set

kernel semantics....

> Does anyone else have any thoughts on the best approach here?

In this case, I don't think it's a distro feature, it's really a package 
configuration option -- the assumption is the rest of the system isn't 
statically linked.  (Our case was that we wanted a static busybox for an initrd...)

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

Re: static busybox?

[Jack Mitchell]

On 31/07/2012 20:59, Mark Hatle wrote:
> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>> We are doing some work with LXC (containers) and one of the templates
>> is for busybox.  For LXC, the busybox package needs to be built 
>> statically and
>> there is a config option for this.
>>
>> A couple possible approaches:
>>
>>     -create a new 'busybox_static' recipe that the lxc package
>>      depends on that turns on the needed build options. Pretty
>>      straightforward, but now there are 2 variants of the busybox
>>      package.
>>
>>     -somehow propagate some configuration options through to
>>      the standard busybox recipe so it turns on the config
>>      option to build things statically.   Not sure how to
>>      do this, and seems like it could get pretty messy.
>>
>> Any thoughts?
>
> We've been talking about this as well..  I'm currently of the opinion 
> that the kernel's config fragement processing be added to busybox.  
> This way someone can simply add a configuration fragment via a 
> bbappend, or other approach and it'll pick it up.   That same can be 
> used to specify how to enable other optional pieces of busybox.

I like this, Busybox is one of the more complex recipes and a way to add 
and subtract config options without keeping your own copy in sync would 
be nice.

Regards,
Jack.

>
> --Mark
>
>> Thanks,
>> Stuart Yoder
>>
>> _______________________________________________
>> 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: static busybox?

[Bruce Ashfield]

On Tue, Jul 31, 2012 at 3:59 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>>
>> We are doing some work with LXC (containers) and one of the templates
>> is for busybox.  For LXC, the busybox package needs to be built statically
>> and
>> there is a config option for this.
>>
>> A couple possible approaches:
>>
>>     -create a new 'busybox_static' recipe that the lxc package
>>      depends on that turns on the needed build options.   Pretty
>>      straightforward, but now there are 2 variants of the busybox
>>      package.
>>
>>     -somehow propagate some configuration options through to
>>      the standard busybox recipe so it turns on the config
>>      option to build things statically.   Not sure how to
>>      do this, and seems like it could get pretty messy.
>>
>> Any thoughts?
>
>
> We've been talking about this as well..  I'm currently of the opinion that
> the kernel's config fragement processing be added to busybox.  This way
> someone can simply add a configuration fragment via a bbappend, or other
> approach and it'll pick it up.   That same can be used to specify how to
> enable other optional pieces of busybox.

merge_config.pl can be yanked out of the kernel source tree (it's upstream) and
packaged as something for use by busy box.

I wouldn't recommend all the scaffolding that the kernel has (it's
overkill, since
there are more configs, patches and git manipulations in play for the
kernel), but a\
simple scheme to collect the fragments from the SRC_URI and fire them through
merge_config.pl would be a pretty simple python routine.

Cheers,

Bruce

>
> --Mark
>
>
>> Thanks,
>> Stuart Yoder
>>
>> _______________________________________________
>> 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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: static busybox?

[Stuart Yoder]

On Tue, Jul 31, 2012 at 3:07 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Tue, Jul 31, 2012 at 3:59 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>>>
>>> We are doing some work with LXC (containers) and one of the templates
>>> is for busybox.  For LXC, the busybox package needs to be built statically
>>> and
>>> there is a config option for this.
>>>
>>> A couple possible approaches:
>>>
>>>     -create a new 'busybox_static' recipe that the lxc package
>>>      depends on that turns on the needed build options.   Pretty
>>>      straightforward, but now there are 2 variants of the busybox
>>>      package.
>>>
>>>     -somehow propagate some configuration options through to
>>>      the standard busybox recipe so it turns on the config
>>>      option to build things statically.   Not sure how to
>>>      do this, and seems like it could get pretty messy.
>>>
>>> Any thoughts?
>>
>>
>> We've been talking about this as well..  I'm currently of the opinion that
>> the kernel's config fragement processing be added to busybox.  This way
>> someone can simply add a configuration fragment via a bbappend, or other
>> approach and it'll pick it up.   That same can be used to specify how to
>> enable other optional pieces of busybox.
>
> merge_config.pl can be yanked out of the kernel source tree (it's upstream) and
> packaged as something for use by busy box.
>
> I wouldn't recommend all the scaffolding that the kernel has (it's
> overkill, since
> there are more configs, patches and git manipulations in play for the
> kernel), but a\
> simple scheme to collect the fragments from the SRC_URI and fire them through
> merge_config.pl would be a pretty simple python routine.

So how would this work from the user's point of view?   I somehow
need to get busybox's CONFIG_STATIC config option set.   Does the lxc
recipe somehow
specify this?   Or does the lxc recipe reference a busybox-static
dependency that sets the option?

Stuart

Re: static busybox?

[Mark Hatle]

On 8/1/12 11:21 AM, Stuart Yoder wrote:
> On Tue, Jul 31, 2012 at 3:07 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
>> On Tue, Jul 31, 2012 at 3:59 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>>>>
>>>> We are doing some work with LXC (containers) and one of the templates
>>>> is for busybox.  For LXC, the busybox package needs to be built statically
>>>> and
>>>> there is a config option for this.
>>>>
>>>> A couple possible approaches:
>>>>
>>>>      -create a new 'busybox_static' recipe that the lxc package
>>>>       depends on that turns on the needed build options.   Pretty
>>>>       straightforward, but now there are 2 variants of the busybox
>>>>       package.
>>>>
>>>>      -somehow propagate some configuration options through to
>>>>       the standard busybox recipe so it turns on the config
>>>>       option to build things statically.   Not sure how to
>>>>       do this, and seems like it could get pretty messy.
>>>>
>>>> Any thoughts?
>>>
>>>
>>> We've been talking about this as well..  I'm currently of the opinion that
>>> the kernel's config fragement processing be added to busybox.  This way
>>> someone can simply add a configuration fragment via a bbappend, or other
>>> approach and it'll pick it up.   That same can be used to specify how to
>>> enable other optional pieces of busybox.
>>
>> merge_config.pl can be yanked out of the kernel source tree (it's upstream) and
>> packaged as something for use by busy box.
>>
>> I wouldn't recommend all the scaffolding that the kernel has (it's
>> overkill, since
>> there are more configs, patches and git manipulations in play for the
>> kernel), but a\
>> simple scheme to collect the fragments from the SRC_URI and fire them through
>> merge_config.pl would be a pretty simple python routine.
>
> So how would this work from the user's point of view?   I somehow
> need to get busybox's CONFIG_STATIC config option set.   Does the lxc
> recipe somehow
> specify this?   Or does the lxc recipe reference a busybox-static
> dependency that sets the option?

You would be able to add a .bbappend that would have a configuration fragment in 
it.  This fragment would be added to the busybox configuration to override any 
built in items.

So you'd need to simply have a file that says:

CONFIG_STATIC = y

--Mark

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

Re: static busybox?

[Darren Hart]

On 07/31/2012 01:01 PM, Mark Hatle wrote:
> On 7/31/12 2:36 PM, McClintock Matthew-B29882 wrote:
>> On Tue, Jul 31, 2012 at 1:14 PM, Stuart Yoder <b08248@gmail.com> wrote:
>>> We are doing some work with LXC (containers) and one of the templates
>>> is for busybox.  For LXC, the busybox package needs to be built statically and
>>> there is a config option for this.
>>>
>>> A couple possible approaches:
>>>
>>>     -create a new 'busybox_static' recipe that the lxc package
>>>      depends on that turns on the needed build options.   Pretty
>>>      straightforward, but now there are 2 variants of the busybox
>>>      package.
>>
>> This would seem to work OK with RDEPENDS += "busybox-static" and just
>> adding the extra static bits for for the static version. It seems OK
>> except we would/could start to get lots of recipes like this.
>>
>>>     -somehow propagate some configuration options through to
>>>      the standard busybox recipe so it turns on the config
>>>      option to build things statically.   Not sure how to
>>>      do this, and seems like it could get pretty messy.
>>
>> Are there any mechanism that currently exist for this? We could turn
>> on a DISTRO_FEATURE if we knew we were going use lxc, but that's more
>> involved than just adding the lxc recipe and getting the right stuff
>> in the root file system.
> 
> Kernel config fragment mechanism is there and IMHO works well for something like 
> this, assuming configuration is using standard
> 
> FOO = value
> 
> # FOO is not set
> 
> kernel semantics....

I've been wanting to get the kernel merge-config mechanism available for
busybox for a while. It definitely seems like the right way to go here.
It could also really simplify some of the logic in the busybox recipe.

--
Darren

> 
>> Does anyone else have any thoughts on the best approach here?
> 
> In this case, I don't think it's a distro feature, it's really a package 
> configuration option -- the assumption is the rest of the system isn't 
> statically linked.  (Our case was that we wanted a static busybox for an initrd...)
> 
>> -M
>>
>> _______________________________________________
>> 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
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: static busybox?

[Darren Hart]

On 08/01/2012 09:36 AM, Mark Hatle wrote:
> On 8/1/12 11:21 AM, Stuart Yoder wrote:
>> On Tue, Jul 31, 2012 at 3:07 PM, Bruce Ashfield
>> <bruce.ashfield@gmail.com> wrote:
>>> On Tue, Jul 31, 2012 at 3:59 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>>> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>>>>>
>>>>> We are doing some work with LXC (containers) and one of the templates
>>>>> is for busybox.  For LXC, the busybox package needs to be built statically
>>>>> and
>>>>> there is a config option for this.
>>>>>
>>>>> A couple possible approaches:
>>>>>
>>>>>      -create a new 'busybox_static' recipe that the lxc package
>>>>>       depends on that turns on the needed build options.   Pretty
>>>>>       straightforward, but now there are 2 variants of the busybox
>>>>>       package.
>>>>>
>>>>>      -somehow propagate some configuration options through to
>>>>>       the standard busybox recipe so it turns on the config
>>>>>       option to build things statically.   Not sure how to
>>>>>       do this, and seems like it could get pretty messy.
>>>>>
>>>>> Any thoughts?
>>>>
>>>>
>>>> We've been talking about this as well..  I'm currently of the opinion that
>>>> the kernel's config fragement processing be added to busybox.  This way
>>>> someone can simply add a configuration fragment via a bbappend, or other
>>>> approach and it'll pick it up.   That same can be used to specify how to
>>>> enable other optional pieces of busybox.
>>>
>>> merge_config.pl can be yanked out of the kernel source tree (it's upstream) and
>>> packaged as something for use by busy box.
>>>
>>> I wouldn't recommend all the scaffolding that the kernel has (it's
>>> overkill, since
>>> there are more configs, patches and git manipulations in play for the
>>> kernel), but a\
>>> simple scheme to collect the fragments from the SRC_URI and fire them through
>>> merge_config.pl would be a pretty simple python routine.
>>
>> So how would this work from the user's point of view?   I somehow
>> need to get busybox's CONFIG_STATIC config option set.   Does the lxc
>> recipe somehow
>> specify this?   Or does the lxc recipe reference a busybox-static
>> dependency that sets the option?
> 
> You would be able to add a .bbappend that would have a configuration fragment in 
> it.  This fragment would be added to the busybox configuration to override any 
> built in items.
> 
> So you'd need to simply have a file that says:
> 
> CONFIG_STATIC = y

Exactly.

And merge_config is a .sh, no perl required :-)

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: static busybox?

[Bruce Ashfield]

On Wed, Aug 1, 2012 at 12:49 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>
>
> On 08/01/2012 09:36 AM, Mark Hatle wrote:
>> On 8/1/12 11:21 AM, Stuart Yoder wrote:
>>> On Tue, Jul 31, 2012 at 3:07 PM, Bruce Ashfield
>>> <bruce.ashfield@gmail.com> wrote:
>>>> On Tue, Jul 31, 2012 at 3:59 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>>>> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>>>>>>
>>>>>> We are doing some work with LXC (containers) and one of the templates
>>>>>> is for busybox.  For LXC, the busybox package needs to be built statically
>>>>>> and
>>>>>> there is a config option for this.
>>>>>>
>>>>>> A couple possible approaches:
>>>>>>
>>>>>>      -create a new 'busybox_static' recipe that the lxc package
>>>>>>       depends on that turns on the needed build options.   Pretty
>>>>>>       straightforward, but now there are 2 variants of the busybox
>>>>>>       package.
>>>>>>
>>>>>>      -somehow propagate some configuration options through to
>>>>>>       the standard busybox recipe so it turns on the config
>>>>>>       option to build things statically.   Not sure how to
>>>>>>       do this, and seems like it could get pretty messy.
>>>>>>
>>>>>> Any thoughts?
>>>>>
>>>>>
>>>>> We've been talking about this as well..  I'm currently of the opinion that
>>>>> the kernel's config fragement processing be added to busybox.  This way
>>>>> someone can simply add a configuration fragment via a bbappend, or other
>>>>> approach and it'll pick it up.   That same can be used to specify how to
>>>>> enable other optional pieces of busybox.
>>>>
>>>> merge_config.pl can be yanked out of the kernel source tree (it's upstream) and
>>>> packaged as something for use by busy box.
>>>>
>>>> I wouldn't recommend all the scaffolding that the kernel has (it's
>>>> overkill, since
>>>> there are more configs, patches and git manipulations in play for the
>>>> kernel), but a\
>>>> simple scheme to collect the fragments from the SRC_URI and fire them through
>>>> merge_config.pl would be a pretty simple python routine.
>>>
>>> So how would this work from the user's point of view?   I somehow
>>> need to get busybox's CONFIG_STATIC config option set.   Does the lxc
>>> recipe somehow
>>> specify this?   Or does the lxc recipe reference a busybox-static
>>> dependency that sets the option?
>>
>> You would be able to add a .bbappend that would have a configuration fragment in
>> it.  This fragment would be added to the busybox configuration to override any
>> built in items.
>>
>> So you'd need to simply have a file that says:
>>
>> CONFIG_STATIC = y
>
> Exactly.
>
> And merge_config is a .sh, no perl required :-)

.. details, details ;)

Bruce

>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Technical Lead - Linux Kernel
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: static busybox?

[McClintock Matthew-B29882]

On Wed, Aug 1, 2012 at 11:36 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 8/1/12 11:21 AM, Stuart Yoder wrote:
>>
>> On Tue, Jul 31, 2012 at 3:07 PM, Bruce Ashfield
>> <bruce.ashfield@gmail.com> wrote:
>>>
>>> On Tue, Jul 31, 2012 at 3:59 PM, Mark Hatle <mark.hatle@windriver.com>
>>> wrote:
>>>>
>>>> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>>>>>
>>>>>
>>>>> We are doing some work with LXC (containers) and one of the templates
>>>>> is for busybox.  For LXC, the busybox package needs to be built
>>>>> statically
>>>>> and
>>>>> there is a config option for this.
>>>>>
>>>>> A couple possible approaches:
>>>>>
>>>>>      -create a new 'busybox_static' recipe that the lxc package
>>>>>       depends on that turns on the needed build options.   Pretty
>>>>>       straightforward, but now there are 2 variants of the busybox
>>>>>       package.
>>>>>
>>>>>      -somehow propagate some configuration options through to
>>>>>       the standard busybox recipe so it turns on the config
>>>>>       option to build things statically.   Not sure how to
>>>>>       do this, and seems like it could get pretty messy.
>>>>>
>>>>> Any thoughts?
>>>>
>>>>
>>>>
>>>> We've been talking about this as well..  I'm currently of the opinion
>>>> that
>>>> the kernel's config fragement processing be added to busybox.  This way
>>>> someone can simply add a configuration fragment via a bbappend, or other
>>>> approach and it'll pick it up.   That same can be used to specify how to
>>>> enable other optional pieces of busybox.
>>>
>>>
>>> merge_config.pl can be yanked out of the kernel source tree (it's
>>> upstream) and
>>> packaged as something for use by busy box.
>>>
>>> I wouldn't recommend all the scaffolding that the kernel has (it's
>>> overkill, since
>>> there are more configs, patches and git manipulations in play for the
>>> kernel), but a\
>>> simple scheme to collect the fragments from the SRC_URI and fire them
>>> through
>>> merge_config.pl would be a pretty simple python routine.
>>
>>
>> So how would this work from the user's point of view?   I somehow
>> need to get busybox's CONFIG_STATIC config option set.   Does the lxc
>> recipe somehow
>> specify this?   Or does the lxc recipe reference a busybox-static
>> dependency that sets the option?
>
>
> You would be able to add a .bbappend that would have a configuration
> fragment in it.  This fragment would be added to the busybox configuration
> to override any built in items.
>
> So you'd need to simply have a file that says:
>
> CONFIG_STATIC = y

This is one approach, to change busybox completely for a specific
added layer. But, what if we only want to make this change to busybox
if the lxc recipe is included in the image? What about other packages
also requesting changes?

-M

> --Mark
>
>
>> Stuart
>>
>> _______________________________________________
>> 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: static busybox?

[Mark Hatle]

On 8/1/12 1:59 PM, McClintock Matthew-B29882 wrote:
> On Wed, Aug 1, 2012 at 11:36 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 8/1/12 11:21 AM, Stuart Yoder wrote:
>>>
>>> On Tue, Jul 31, 2012 at 3:07 PM, Bruce Ashfield
>>> <bruce.ashfield@gmail.com> wrote:
>>>>
>>>> On Tue, Jul 31, 2012 at 3:59 PM, Mark Hatle <mark.hatle@windriver.com>
>>>> wrote:
>>>>>
>>>>> On 7/31/12 1:14 PM, Stuart Yoder wrote:
>>>>>>
>>>>>>
>>>>>> We are doing some work with LXC (containers) and one of the templates
>>>>>> is for busybox.  For LXC, the busybox package needs to be built
>>>>>> statically
>>>>>> and
>>>>>> there is a config option for this.
>>>>>>
>>>>>> A couple possible approaches:
>>>>>>
>>>>>>       -create a new 'busybox_static' recipe that the lxc package
>>>>>>        depends on that turns on the needed build options.   Pretty
>>>>>>        straightforward, but now there are 2 variants of the busybox
>>>>>>        package.
>>>>>>
>>>>>>       -somehow propagate some configuration options through to
>>>>>>        the standard busybox recipe so it turns on the config
>>>>>>        option to build things statically.   Not sure how to
>>>>>>        do this, and seems like it could get pretty messy.
>>>>>>
>>>>>> Any thoughts?
>>>>>
>>>>>
>>>>>
>>>>> We've been talking about this as well..  I'm currently of the opinion
>>>>> that
>>>>> the kernel's config fragement processing be added to busybox.  This way
>>>>> someone can simply add a configuration fragment via a bbappend, or other
>>>>> approach and it'll pick it up.   That same can be used to specify how to
>>>>> enable other optional pieces of busybox.
>>>>
>>>>
>>>> merge_config.pl can be yanked out of the kernel source tree (it's
>>>> upstream) and
>>>> packaged as something for use by busy box.
>>>>
>>>> I wouldn't recommend all the scaffolding that the kernel has (it's
>>>> overkill, since
>>>> there are more configs, patches and git manipulations in play for the
>>>> kernel), but a\
>>>> simple scheme to collect the fragments from the SRC_URI and fire them
>>>> through
>>>> merge_config.pl would be a pretty simple python routine.
>>>
>>>
>>> So how would this work from the user's point of view?   I somehow
>>> need to get busybox's CONFIG_STATIC config option set.   Does the lxc
>>> recipe somehow
>>> specify this?   Or does the lxc recipe reference a busybox-static
>>> dependency that sets the option?
>>
>>
>> You would be able to add a .bbappend that would have a configuration
>> fragment in it.  This fragment would be added to the busybox configuration
>> to override any built in items.
>>
>> So you'd need to simply have a file that says:
>>
>> CONFIG_STATIC = y
>
> This is one approach, to change busybox completely for a specific
> added layer. But, what if we only want to make this change to busybox
> if the lxc recipe is included in the image? What about other packages
> also requesting changes?

There is no method within OE to change a configuration of one item, if another 
item is included or not.

The way to do this is use the PACKAGECONFIG options, and then pass via a 
per-recipe configuration if you want lxc support enabled or not.. (or possible 
lxc becomes a distro flag?)

--Mark

> -M
>
>> --Mark
>>
>>
>>> Stuart
>>>
>>> _______________________________________________
>>> 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: static busybox?

[Otavio Salvador]

On Wed, Aug 1, 2012 at 4:05 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 8/1/12 1:59 PM, McClintock Matthew-B29882 wrote:
>> This is one approach, to change busybox completely for a specific
>> added layer. But, what if we only want to make this change to busybox
>> if the lxc recipe is included in the image? What about other packages
>> also requesting changes?
>
> There is no method within OE to change a configuration of one item, if
> another item is included or not.
>
> The way to do this is use the PACKAGECONFIG options, and then pass via a
> per-recipe configuration if you want lxc support enabled or not.. (or
> possible lxc becomes a distro flag?)

For lxc specific case I think we can just have a recipe that sets the
busybox' static option. It seems to be the only difference we'd have
for it.

Having compile options changing by other packages is going to be a
mess since we'll not know what to expect of build options of the
application/library (in this case busybox).



-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: static busybox?

[Stuart Yoder]

On Wed, Aug 1, 2012 at 3:05 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> On Wed, Aug 1, 2012 at 4:05 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 8/1/12 1:59 PM, McClintock Matthew-B29882 wrote:
>>> This is one approach, to change busybox completely for a specific
>>> added layer. But, what if we only want to make this change to busybox
>>> if the lxc recipe is included in the image? What about other packages
>>> also requesting changes?
>>
>> There is no method within OE to change a configuration of one item, if
>> another item is included or not.
>>
>> The way to do this is use the PACKAGECONFIG options, and then pass via a
>> per-recipe configuration if you want lxc support enabled or not.. (or
>> possible lxc becomes a distro flag?)
>
> For lxc specific case I think we can just have a recipe that sets the
> busybox' static option. It seems to be the only difference we'd have
> for it.

Do you mean a distinct 'busybox-static' recipe that lxc would
depend on?

Stuart

Re: static busybox?

[Koen Kooi]

Op 3 aug. 2012, om 00:50 heeft Stuart Yoder <b08248@gmail.com> het volgende geschreven:

> On Wed, Aug 1, 2012 at 3:05 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> On Wed, Aug 1, 2012 at 4:05 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 8/1/12 1:59 PM, McClintock Matthew-B29882 wrote:
>>>> This is one approach, to change busybox completely for a specific
>>>> added layer. But, what if we only want to make this change to busybox
>>>> if the lxc recipe is included in the image? What about other packages
>>>> also requesting changes?
>>> 
>>> There is no method within OE to change a configuration of one item, if
>>> another item is included or not.
>>> 
>>> The way to do this is use the PACKAGECONFIG options, and then pass via a
>>> per-recipe configuration if you want lxc support enabled or not.. (or
>>> possible lxc becomes a distro flag?)
>> 
>> For lxc specific case I think we can just have a recipe that sets the
>> busybox' static option. It seems to be the only difference we'd have
>> for it.
> 
> Do you mean a distinct 'busybox-static' recipe that lxc would
> depend on?

Exactly, we already had exactly that in OE-classic

Re: static busybox?

[Otavio Salvador]

On Thu, Aug 2, 2012 at 7:50 PM, Stuart Yoder <b08248@gmail.com> wrote:
> On Wed, Aug 1, 2012 at 3:05 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> On Wed, Aug 1, 2012 at 4:05 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 8/1/12 1:59 PM, McClintock Matthew-B29882 wrote:
>>>> This is one approach, to change busybox completely for a specific
>>>> added layer. But, what if we only want to make this change to busybox
>>>> if the lxc recipe is included in the image? What about other packages
>>>> also requesting changes?
>>>
>>> There is no method within OE to change a configuration of one item, if
>>> another item is included or not.
>>>
>>> The way to do this is use the PACKAGECONFIG options, and then pass via a
>>> per-recipe configuration if you want lxc support enabled or not.. (or
>>> possible lxc becomes a distro flag?)
>>
>> For lxc specific case I think we can just have a recipe that sets the
>> busybox' static option. It seems to be the only difference we'd have
>> for it.
>
> Do you mean a distinct 'busybox-static' recipe that lxc would
> depend on?

Yes; it might include the regular busybox recipe and do the need
appends, or something like that.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: static busybox?

[Mark Hatle]

On 8/3/12 6:19 AM, Otavio Salvador wrote:
> On Thu, Aug 2, 2012 at 7:50 PM, Stuart Yoder <b08248@gmail.com> wrote:
>> On Wed, Aug 1, 2012 at 3:05 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>> On Wed, Aug 1, 2012 at 4:05 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>>> On 8/1/12 1:59 PM, McClintock Matthew-B29882 wrote:
>>>>> This is one approach, to change busybox completely for a specific
>>>>> added layer. But, what if we only want to make this change to busybox
>>>>> if the lxc recipe is included in the image? What about other packages
>>>>> also requesting changes?
>>>>
>>>> There is no method within OE to change a configuration of one item, if
>>>> another item is included or not.
>>>>
>>>> The way to do this is use the PACKAGECONFIG options, and then pass via a
>>>> per-recipe configuration if you want lxc support enabled or not.. (or
>>>> possible lxc becomes a distro flag?)
>>>
>>> For lxc specific case I think we can just have a recipe that sets the
>>> busybox' static option. It seems to be the only difference we'd have
>>> for it.
>>
>> Do you mean a distinct 'busybox-static' recipe that lxc would
>> depend on?
>
> Yes; it might include the regular busybox recipe and do the need
> appends, or something like that.
>

That would certainly be my recommendation.  Use the same base recipe, same 
configuration mechanism, and then just add the addition chunk(s) to the SRC_URI 
and it should be much easier to maintain long-term.

The only thing remaining, is anyone working on adding the configuration yet? 
(I'd love to, but I'm swamped with work for about the next 2-3 weeks.)

--Mark