Hi Raj > > > > On Apr 1, 2016, at 5:38 AM, Isak Lichtenstein > > <isak.lichtenst...@kistler.com> > wrote: > > > > Hi Joël, > >> > >> Hi, > >> > >> One idea may be to create one recipe per configuration file. > >> So in each image recipe, you would add one of those recipes to > >> IMAGE_INSTALL_append. > > > > That's exactly what I'm doing now. But as my base package "A" is in a > > layer that is used by other developers, I would like to enforce > > somehow that every image containing this package also provides a > > config package for it. > > you can use bitbake diagnostics in a image post process function to implement > this logic or in a bbclass which is inherited by every image you build.
Thank you for your suggestion. Will try to solve it as you suggest, but I will need to kneel myself into the bitbake library classes to see what methods they provide to easily implement this bbclass. > >> > Hi, > >> > > >> > I've got a package "A" that has a runtime dependency to a configuration > >> > file. > >> > This configuration file is image specific. For each image I've got a > >> > specific configuration package "config-image-X" that installs this > >> > needed configuration file and I build multiple image in the same build > >> > directory. > >> > How can I enforce that each image containing package "A" also installs > >> > an image specific configuration package? > >> > I've tried with virtual providers, but then at the second image it > >> > always tried to install the virtual provider from the first image as > >> > well, which leads to the following failure during the rootfs task: > >> > > >> > check_data_file_clashes: Package config-image-1 wants to install file > >> > /home/root/build/build_dev/tmp/work/poky-linux-gnueabi/core-image- > >> > test/1.0-r0/rootfs/usr/bin/config > >> > But that file is already provided by package * config-image-2 Nevertheless, when I tried using the provider class, I found it's behavior a bit weird. When I have a package build dependency and 2 providers, I expect that Yocto pull in/uses the provider with the highest priority. But if a package has got a run time dependency, and the image containing the package also includes already a provider for the package, I would expect that the run time dependency is satisfied despite the provider included isn't the one with the highest prio. In reality I found that the image always tried to also include the highest prio provider. Is that really the expected behavior? BR Isak -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto