[bitbake-devel] [PATCH v2][2/2] image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package

[Jate Sujjavanich]

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.

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".

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.


- Jate


On Thu, May 14, 2015 at 5:46 AM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Wed, 2015-05-13 at 18:47 -0400, Jate Sujjavanich wrote:
> > +python rootfs_process_preferred_rproviders() {
> > +    inst_pkgs = d.getVar("PACKAGE_INSTALL", True).split()
> > +    pref_pkgs = list()
> > +    for pkg in inst_pkgs:
> > +        prefervar = d.getVar("PREFERRED_RPROVIDER_%s" % pkg, True)
> > +        if prefervar:
> > +            inst_pkgs.remove(pkg)
> > +            pref_pkgs.append(prefervar)
> > +            bb.note("Selecting %s to provide %s due to
> > PREFERRED_RPROVIDER" % (prefervar, pkg))
> > +    inst_pkgs.extend(pref_pkgs)
> > +    d.setVar("PACKAGE_INSTALL", ' '.join(inst_pkgs))
> > +}
> > +do_rootfs[prefuncs] += "rootfs_process_preferred_rproviders"
> > +
> >  # We have to delay the runtime_mapping_rename until just before
> > rootfs runs
> >  # otherwise, the multilib renaming could step in and squash any
> > fixups that
> >  # may have occurred.
>
> This kind of approach to the problem basically doesn't scale. Yes, it
> will rewrite things in PACKAGE_INSTALL however if package A depends on
> package B using one of these names, the mechanism will simply not work.
> This will in turn generate a whole new world of bug reports with no way
> to really fix the problems.
>
> This is why we have other mechanisms for handling the runtime provider
> names, usually through parametrisation with variables so that when you
> rewrite an entry, *all* entries get rewritten and what the package
> manager sees is consistent.
>
> I would also note that in the past, bitbake once did have
> PREFERRED_RPROVIDER support. We dropped it as it caused problems. I
> suspect I would have written up some rationale for that when we did it
> which would be in the list archives.
>
> Cheers,
>
> Richard
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20150527/9cf3be42/attachment-0002.html>