Enable a recipe/package only when other dependent recipe/package is part of image.
Hello,
I have my own layer, that provides configuration packages for core Linux components, for example ‘connman-conf’ for ‘connman’ package.
I would like to provide a pakcagegroup-config, that should automatically select the configuration packages that are part of image configuration. Say if ‘connman’ is part of image then it should add ‘connman-conf’ to its RDEPENDS_${PN}.
For this I tried to use ‘oe.packagedata.pkgmap’, to check if the core component exists as below:
--------------------------------------------------------------------
def check_if_enabled(comp, trueval, d):
import oe.packagedata
pkgmap = oe.packagedata.pkgmap(d)
if pkgmap is not None and pkgmap.get(comp) is not None:
return trueval
return “”
RDEPENDS_${PN} = “ \
${@check_if_enabled(“connman”, “connman-conf”, d)} \
“
-----------------------------------------------------------
This works as expected when the packagedata is available, i.e., image is build at least once first, then my layer is added to BBLAYERS and then rebuild the image.
But this fails when there is no packagedata cache available.
Can someone help me to resolve this properly.
Thanks,
Amarnath
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Quoted 6 lines · Amarnath Valluri
I would like to provide a pakcagegroup-config, that should automatically select the configuration packages that are part of image configuration. Say if ‘connman’ is part of image then it should add ‘connman-conf’ to its RDEPENDS_${PN}.
You can't do that.
A packagegroup is just a recipe that generates packages with no contents, just dependencies. They are built once and don't know what image they're being "built for", or what other packages are being built. What would you packagegroup do if it were built directly, not via dependencies from an image?
The low-fi way to implement this would be for the layer that adds connman-conf to also add a bbappend for connman to depend on connman-conf.
An alternative would be to have some naming pattern for conf packages (-conf is reasonable) and invent a new image-feature called conf-packages that uses a glob to find all complementary packages matching the *-conf pattern. This is how dev-pkgs, dbg-pkgs, doc-pkgs etc work. I believe this is just a matter of setting COMPLEMENTARY_GLOB[conf-pkgs] = '*-conf' in your configuration.
Ross
Thanks Ross for your suggestions.
Quoted 9 lines · Ross
On 25 April 2016 at 07:46, Amarnath Valluri <[email protected] <mailto:[email protected]>> wrote:
I would like to provide a pakcagegroup-config, that should automatically select the configuration packages that are part of image configuration. Say if ‘connman’ is part of image then it should add ‘connman-conf’ to its RDEPENDS_${PN}.
Quoted 3 lines
You can't do that.
A packagegroup is just a recipe that generates packages with no contents, just dependencies. They are built once and don't know what image they're being "built for", or what other packages are being built. What would you packagegroup do if it were built directly, not via dependencies from an image?
Yes, i agree.
Quoted 2 lines
The low-fi way to implement this would be for the layer that adds connman-conf to also add a bbappend for connman to depend on connman-conf.
I considered this initially, but the issue with .bbappend is it leads to rebuilding of core packages when this configuration layer add to bblayers, to (re)build image, which we would like to avoid.
Quoted 2 lines
An alternative would be to have some naming pattern for conf packages (-conf is reasonable) and invent a new image-feature called conf-packages that uses a glob to find all complementary packages matching the *-conf pattern. This is how dev-pkgs, dbg-pkgs, doc-pkgs etc work. I believe this is just a matter of setting COMPLEMENTARY_GLOB[conf-pkgs] = '*-conf' in your configuration.
I will try this, thanks.
- Amarnath
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi Ross,
Quoted 4 lines
Quoted 3 lines
An alternative would be to have some naming pattern for conf packages (-conf is reasonable) and invent a new image-feature called conf-packages that uses a glob to find all complementary packages matching the *-conf pattern. This is how dev-pkgs, dbg-pkgs, doc-pkgs etc work. I believe this is just a matter of setting COMPLEMENTARY_GLOB[conf-pkgs] = '*-conf' in your configuration.
I will try this, thanks.
I tried this solution:
COMPLEMENTARY_GLOB[conf-pkgs] = '*-conf'
IMAGE_FEATURES_append = " conf-pkgs"
But this did not work for me. The obvious reason(i guess) is no matching packages build for '*-conf', though all configuration recipes provides '<base_component>-conf' packages, but the dependency is missing to build those packages :(.
My layer provides configuration packages for core components, such as 'connman', 'openssh', 'dropbear', etc., which needs to/can be configured with our configuration framework. I would like to find a way to pick the corresponding config packages based on the image configuration, for example 'openssh-conf' or 'dropbear-conf' whichever the image is configured to use.
Thanks,
Amarnath
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.