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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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