dustymabe added a new comment to an issue you are following: ``
There is a probability that the older updates have had the signed copies cleaned up on disk before hand, assuming it was the previous build.
I believe @mikeb did not think this was a problem because if we tag them into `f27-atomic-overrides` they won't be gc by koji??
Rather than using dist-repos we should use pungi to make the repo.
dist repo was because we'd only need to change this repo few times and we can just run the create the dist repo command right after we tagged a package into the tag. The ostree creation (that runs during bodhi call to pungi) would pick up rpms from f27 release, the f27 updates run that was just done as part of the bodhi run, AND the dist-repo. The goal is to prevent having to create the atomic overrides repo as part of the bodhi run every day.
A side effect of this change is that you are unlikely to get the result that you want. as when anaconda sees the updates in the updates repo witha higher nvr it will choose that. you will need to manage the entire chain of packages in the pungi compose to get your intended behaviour.
The installer would come from the `f27-atomic-installer` tag which inherits from `f27` release tag. Similar to today, it wouldn't pull in updates. The ostree that gets embedded in the installer would be the one from the bodhi updates run and it would already have the `f27-atomic-overrides` packages baked into the ostree. Anaconda has no ability to pull newer updates, the ostree is already baked.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7100