Prep patches for setting up branched/next-devel/next #180
Conversation
That way e.g. `next` can have `releasever: 31`.
For completeness.
These will be needed by the new `branched`/`next-devel`/`next` streams.
|
So basically, there's two ways to approach the "config" problem here: we could keep I'm leaning more towards the first approach for now (with |
|
One hiccup where I see difficulties is if we want to carry something in the overlay only on one of the two streams. Right now, I think it'd be cleaner if we folded the Another cleanup from doing this is that intermediate manifests would be able to reference the overlays to which they "correspond". (E.g. |
|
📞 ? |
|
What is fedora-next.repo? Is it rawhide? Is it f31? If it's f31 then why not just let the releasever control it and use fedora.repo ? |
It's the set of repos that
The paths are not the same yet. |
right.. if we were using the metalink URLs it wouldn't matter but since we are using stable URLs (i.e. no mirrors) it does. Got ya. |
|
this LGTM. Regarding the "managing the config" I'm afraid I don't have a good answer right now :(. In Fedora we use a branch for each release and then manually pull back stuff that we need. In this repo it's not always clear where the most development will be happening (i.e. not one clear upstream to everything like rawhide is in Fedora proper) so we'll have to organically come up with something that works for us. |
|
Will merge this after promoting for a release! |
For now we inherit from testing-devel; see discussions starting from: coreos/fedora-coreos-config#180 (comment)
When this file is present in the config dir, coreos-assembler will still automatically commit the `overlay.d` subdirectories to the OSTree repo, but will not automatically add them to the treefile. This provides more flexibility on the config side, where e.g. overlays may be conditionally added or may only be added on certain streams. This has come up multiple times already in FCOS, more recently as part of the `iptables-nft` migration work. See also: coreos/fedora-coreos-config#180 (comment) So this is sort of a halfway approach between what we have now and teaching rpm-ostree about the overlay directories directly (via a new e.g. `add-dirs` file, see previous discussions about this in coreos#639). Except that this is much easier to do and doesn't require any rpm-ostree modification.
When this file is present in the config dir, coreos-assembler will still automatically commit the `overlay.d` subdirectories to the OSTree repo, but will not automatically add them to the treefile. This provides more flexibility on the config side, where e.g. overlays may be conditionally added or may only be added on certain streams. This has come up multiple times already in FCOS, more recently as part of the `iptables-nft` migration work. See also: coreos/fedora-coreos-config#180 (comment) So this is sort of a halfway approach between what we have now and teaching rpm-ostree about the overlay directories directly (via a new e.g. `add-dirs` file, see previous discussions about this in #639). Except that this is much easier to do and doesn't require any rpm-ostree modification.
Move the
releaseverkey tomanifest.yaml, and add branched development yum repo definitions.