Build Flavors

[ignatenkobrain]

Following our conversation from IRC:

repo system 0 empty
repo available 0 testtags <inline>
#>=Pkg: platform:f28 2018 1 noarch
#>=Pkg: platform:f28 2019 1 noarch
#>=Pkg: platform:f29 2018 1 noarch
#>=Pkg: platform:f29 2019 1 noarch
#>=Pkg: gtk3:3.30 2019 1 noarch
#>=Req: platform:f28
#>=Pkg: gtk3:3.30 2019 1 noarch
#>=Req: platform:f29
#>=Pkg: app 1 1 noarch
#>=Req: gtk3:3.30

system x86_64 rpm system

poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job install name app
result transaction,problems,alternatives,reason,rules <inline>

This doesn't create alternatives, so if you add job install platform:f29, you end up with both f28 and f29, so the code for optimizing transaction doesn't know how to handle these. This might be bug unrelated to my issue, not sure.

In case above, I would like to get alternatives for two GTKs first (because all platforms are installable), and latest platforms (i.e. 2019).

@mlschroe pointed out that this is because prune_to_best_version filters by name.

So I think we need to prune by name+flavor to latest evr. However, this might result to having foo:latest 2010 which had "bar" flavor (and then it got deprecated). Pruning to latest version by just name, and keeping whatever left with different flavors is probably good way to go. I would prefer latter.

Probably we just need flag to tweak this.

[ignatenkobrain]

ah, and one thing which should be probably implemented: switching between flavors (either automatically or with some flag). This would probably involve adding new transaction type like switching, replacing or something like that.

[mlschroe]

But wouldn't you put the platform in the package name for the gtk3:3.30 package? E.g. gtk3:3.30:f28-2019-1?

[ignatenkobrain]

@mlschroe no, because it might not be only platform. It might be combination of platform+ruby+python+whatsoever.