Conditionally enable virtualization packages in qcom-multimedia-image

[vkraleti]

Guard packages provided by meta-virtualization layer with virtualization
DISTRO_FEATURE so they are omitted when users disable virtualization,
preventing unnecessary dependencies from being pulled into the image.

[ricardosalveti]

One of the use cases we have for the multimedia-image is to be able to run the multimedia-related use cases in a container, so not sure if this separation is ideal here.

I would just have it on both.

[vkraleti]

Test teams agreed to pick container orchestration image for verifying the multimedia-related use cases inside a container. So testing part is covered.

docker‑compose pulls in Go projects hosted on Google cloud for compilation. Due to region‑specific access restrictions, these sources are not reachable in certain geographies. Since it is included in every image, users in these regions are currently unable to build anything. Dropping docker‑compose allows them to build the multimedia image without access restrictions.

[ricardosalveti]

Test teams agreed to pick container orchestration image for verifying the multimedia-related use cases inside a container. So testing part is covered.

Sure, but I still think docker (without kube* and family) is more useful in a generic way, and today people normally expect the standard distro image to have it.

docker‑compose pulls in Go projects hosted on Google cloud for compilation. Due to region‑specific access restrictions, these sources are not reachable in certain geographies. Since it is included in every image, users in these regions are currently unable to build anything. Dropping docker‑compose allows them to build the multimedia image without access restrictions.

Right, this is a different problem and we should try to identify ways to fix it, since we do expect to have go-lang based projects integrated by default here (we should not block golang simply because of region-specific access restrictions).

[DapengYuan-David]

Sure, but I still think docker (without kube* and family) is more useful in a generic way, and today people normally expect the standard distro image to have it.

Yes, agreed. In addition, we actually have features that depend on Docker enablement.

[vkraleti]

Sure, but I still think docker (without kube* and family) is more useful in a generic way, and today people normally expect the standard distro image to have it.

Yes, agreed. In addition, we actually have features that depend on Docker enablement.

Ok, understood. I updated the patch to bring in docker-compose with a feature check so that users have option to disable the distro feature to avoid it when needed.