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