compose: If repos is unset, use global ones

[cgwalters]

Part of https://gitlab.com/fedora/bootc/tracker/-/issues/32

This will simplify the hacks we have in Containerfile there.
As part of this intended UX, the repositories come from the
global set.

Signed-off-by: Colin Walters walters@verbum.org

[travier]

LGTM. Not tested. Maybe we should add a small test to make sure we'll not pick up repos from the host if we've set some to make sure we don't regress the current setup?

[cgwalters]

I think a lot of things in the existing test suite would start to blow up if we leaked the host repos...but you're right. Testing this explicitly is clearly doable, just need to figure out where.

Hmm...I dunno. I may actually instead do a different spike on "productizing" https://gitlab.com/fedora/bootc/base-images-experimental/-/blob/main/build/dnf-installroot

[cgwalters]

Moving this back to draft, it's not in a blocking path right now.

[jlebon]

So, I opened #5136 which proposes a different semantic: if repos is missing, we don't change the reposdir (i.e. we still scan for repos sitting alongside treefiles). But we don't touch any enablement; we let the enablement set in those repo files win, which is what libdnf does by default. This seems safer and less surprising conceptually and fits nicely with the needs of the current fedora-bootc container-native flow.

If we want to support mutating the reposdir down the line, I would propose maybe setting something on the CLI instead (e.g. rpm-ostree compose image --add-reposdir ...)?

[cgwalters]

And you're arguing then for rpm-ostree compose image --add-reposdir /etc/yum.repos.d to get the semantics I was doing here?

[jlebon]

And you're arguing then for rpm-ostree compose image --add-reposdir /etc/yum.repos.d to get the semantics I was doing here?

That's one suggestion. The main argument I think is that "no repos means leave default enablement" is an easier to understand behaviour because it operates on the same axis (repos has always been about enablement).

How we implement "use host repos" if we also want that is a separate question. The CLI argument idea comes more from my estimation that this kind of behaviour is more a "how you run rpm-ostree" question rather than treefile definitions, so it seems more appropriate than a e.g. reposdir: knob there.