input: add support for package aliases

[jkloetzke]

Virtual packages transparently create an alias for a recipe. They are configured by yaml files in the newly defined virtual directory. For example, the file virtual/libs/libegl.yaml

multiPackage:
    "":  ${CONFIG_SELECT_LIBEGL:-libs::mesa3d}
    dev: ${CONFIG_SELECT_LIBEGL:-libs::mesa3d}-dev
    tgt: ${CONFIG_SELECT_LIBEGL:-libs::mesa3d}-tgt

would create packages libs::libegl, libs::libegl-dev and libs::libegl-tgt whose underlying recipe is selected by CONFIG_SELECT_LIBEGL.

If there is only one package, the yaml file can be a simple string containing just the target name.

[codecov]

Codecov Report

Attention: Patch coverage is 90.38462% with 10 lines in your changes missing coverage. Please review.

Project coverage is 88.86%. Comparing base (3909513) to head (dc7f3ad).
Report is 6 commits behind head on master.

Files with missing lines	Patch %	Lines
pym/bob/input.py	90.09%	10 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #609      +/-   ##
==========================================
- Coverage   88.87%   88.86%   -0.01%     
==========================================
  Files          48       48              
  Lines       15551    15629      +78     
==========================================
+ Hits        13821    13889      +68     
- Misses       1730     1740      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jkloetzke]

@sixtyfourktec @rhubert It would be nice to get you feedback here. Given the "virtual" packages in basement-gnu-linux, I figured some native support should be provided. Especially since it's not possible to virtualize tools at all at the moment.

This PR is the bare minimum feature set that I could think of. Is this enough from your POV or do we need something more for proper virtual packages..?

[rhubert]

👍 Look good + sufficient to me.

Only a quick idea: What about virtual classes? I'm thinking of the the integration clang, where something like a virtual::clang class could solve the issue of using clang or not without touching the recipes...maybe... not thought to the end...

[jkloetzke]

Thanks for looking into it. I'm currently leaning to name this alias instead of virtual. Because it's creating an alias for an existing package. There is also #314 which requires the same underlying mechanism to create multiple dependencies to the same recipe by giving them distinct names:

depends:
    - name: bar
      alias: bar-one
      environment:
        CONFIG_BAR: "one"
    - name: bar
      alias: bar-two
      environment:
        CONFIG_BAR: "two"

As for classes I'm not sure if this will work. The aliases are created after all classes have been resolved already. But I have to think about this too...

[jkloetzke]

Ok, so I renamed everything consistently to "alias". There are now global aliases that are configured in the aliases directory as YAML files. And then there are local aliases where each dependency in the depends list can get a different (but still locally unique) name.

@daxcore you might want to try out the local aliases. Any feedback if this fits your needs is highly appreciated. :)

More tests and the documentation are still missing, though...