#1449 Repos from one variant end up as input to an ostree compose in a different variant
Opened 3 years ago by otaylor. Modified 3 years ago

In https://pagure.io/pungi-fedora/blob/f33/f/variants-fedora.xml we have:

    <variant id="Silverblue" name="Silverblue" type="variant" is_empty="true">  
        <arches>
            <arch>aarch64</arch>
            <arch>armhfp</arch>
            <arch>x86_64</arch>
            <arch>ppc64le</arch>
        </arches>
    </variant>
    <variant id="Modular" name="Modular" type="variant">
        <arches>
            <arch>armhfp</arch>
            <arch>aarch64</arch>
            <arch>ppc64le</arch>
            <arch>s390x</arch>
            <arch>x86_64</arch>
        </arches>
        <modules>
            <kojitag>f33-modular</kojitag>
        </modules>
    </variant>

So the inclusion of the f33-modular tagged modules should be specific to the Modular variant, but the module repositories from f33-modular end up as input to the ostree compose in the Silverblue variant - see https://kojipkgs.fedoraproject.org/compose/branched/Fedora-33-20200917.n.0/work/ostree-1/extra_config.json.

This is problematic because rpm-ostree doesn't understand modules and just includes all the packages in the modules as candidates for normal installation.

This caused https://github.com/fedora-silverblue/issue-tracker/issues/82 The inclusion of the Flatpak modules in f33-modular was accidental because of https://pagure.io/releng/issue/9758, but I think the problem is general.


There's no mixing of variants here since at the time when rpm-ostree is running, the repos for variants don't exist yet. The task has access to repos that contain all packages available in all Koji tags (including modules). The repos with modular packages have correct metadata in them.

It hasn't always been like that, it was changed in #778 to make things faster.

If rpm-ostree had module support and modules were just ignored except when enabled, I'd agree that that just providing everything as input might be a "good enough" optimization that wouldn't matter in most cases.

The problem here is that rpm-ostree has no support for modules (https://github.com/coreos/rpm-ostree/issues/1435) so providing the module repositories as input for rpm-ostree does the wrong thing - the highest NVR in any repository will be used, without considering what modules are enabled.

So perhaps the right formulation here is more "don't pass modular repositories to the ostree compose" than anything related to variants.

Login to comment on this ticket.

Metadata