Use per-flavor Dockerfiles

[kkaempf]

This reverts the single, flavored Dockerfile to many, per-flavor ones.

Turns out that build service gets confused with multiple (intended to be per-flavor) zypper calls and lumps them all into one trying to resolve dependencies.

This fails e.g. with the 'standard' image (trying to install multipath-tools) combined with the kvm image (trying to replace kernel-default with kernel-default-base), leading to multipath-tools being uninstallable (because it needs kernel-default and can't work with kernel-default-base).

[davidcassany]

This fails e.g. with the 'standard' image (trying to install multipath-tools) combined with the kvm image (trying to replace kernel-default with kernel-default-base), leading to multipath-tools being uninstallable (because it needs kernel-default and can't work with kernel-default-base).

ouch 🤦🏽‍♂️

Yes the flavors would be really cool, but there are too many rocks in the path. They are far from smooth and the setup turn to be way too convoluted to make real use of them... I fully agree on splitting all in different Dockerfiles. Later on we can revisit building all them in a single OBS package but using individual dockerfiles, we could do this by improving a little the OBS buildtime services. But that for later.

[kkaempf]

/backport v2.0.x