<div dir="ltr"><div><div>I have taken a look at the code, and there two places that I have found so far that contain the RPROVIDES_* for each package. One is the taskdata at the bitbake level, and the other is the pkgdata directory within the sysroot for the machine's build. The taskdata seems more readily accessible in memory. However, I've neither figured out a way to access it from the image recipe namespace, nor do I know if it's intended to be accessed at the recipe level. On the other hand, the pkgdata directory holds information about all built packages, and I've written some code derived from packageinfo.bbclass (used in hob) that loads all the package information into memory.<br><br>For the case provided in bug 6149, the code could access the PREFERRED_PROVIDER for the missing sshd package, search the pkgdata, and then replace 'sshd' within PACKAGE_INSTALL with 'dropbear' as specified within RPROVIDES_dropbear = "ssh sshd".<br><br></div>A problem is the inefficiency of parsing through the pkgdata files. Maybe a rewrite of IMAGE_INSTALL be done during the calculations taskdata.py instead, or maybe the name of the package rproviding the item needs to be saved and referred to during the image generation.<br><br></div><br>- Jate<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 14, 2015 at 5:46 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2015-05-13 at 18:47 -0400, Jate Sujjavanich wrote:<br>
> +python rootfs_process_preferred_rproviders() {<br>
> + inst_pkgs = d.getVar("PACKAGE_INSTALL", True).split()<br>
> + pref_pkgs = list()<br>
> + for pkg in inst_pkgs:<br>
> + prefervar = d.getVar("PREFERRED_RPROVIDER_%s" % pkg, True)<br>
> + if prefervar:<br>
> + inst_pkgs.remove(pkg)<br>
> + pref_pkgs.append(prefervar)<br>
> + bb.note("Selecting %s to provide %s due to<br>
> PREFERRED_RPROVIDER" % (prefervar, pkg))<br>
> + inst_pkgs.extend(pref_pkgs)<br>
> + d.setVar("PACKAGE_INSTALL", ' '.join(inst_pkgs))<br>
> +}<br>
> +do_rootfs[prefuncs] += "rootfs_process_preferred_rproviders"<br>
> +<br>
> # We have to delay the runtime_mapping_rename until just before<br>
> rootfs runs<br>
> # otherwise, the multilib renaming could step in and squash any<br>
> fixups that<br>
> # may have occurred.<br>
<br>
</span>This kind of approach to the problem basically doesn't scale. Yes, it<br>
will rewrite things in PACKAGE_INSTALL however if package A depends on<br>
package B using one of these names, the mechanism will simply not work.<br>
This will in turn generate a whole new world of bug reports with no way<br>
to really fix the problems.<br>
<br>
This is why we have other mechanisms for handling the runtime provider<br>
names, usually through parametrisation with variables so that when you<br>
rewrite an entry, *all* entries get rewritten and what the package<br>
manager sees is consistent.<br>
<br>
I would also note that in the past, bitbake once did have<br>
PREFERRED_RPROVIDER support. We dropped it as it caused problems. I<br>
suspect I would have written up some rationale for that when we did it<br>
which would be in the list archives.<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
</blockquote></div><br></div>