Learn more about these different git repos.
Other Git URLs
Ostree configuration specifies a list of packages that should be pulled in. There is no particular reason why it would need to consume the packages from the final per variant repository and could not use the same repo that buildinstall phase is using.
buildinstall
The advantage of doing this is that we could start making ostrees (and then ostree installers) immediately after pkgset phase finishes, which could save time.
pkgset
Another advantage is that it would no longer be required to specify repository in the config (Fedora Atomic now uses either Everything or Workstation variants as source repo, those would instead use the same work/$basearch/repo). Less config is better.
work/$basearch/repo
The downside is that some error edge cases would change. Right now if the treefile listed a package that is not in the variant but exists in the package set, the ostree task would fail. With this change it would still work.
Implementation detail: care should be taken to make sure all parallel phases are correctly stopped if something goes wrong. Otherwise we'll be getting deadlocks…
The variant stuff so far (AFAICS) has just been something we drag through the release process to keep working since it's used by at least one downstream. Now that bodhi uses pungi, we could actually consider generating different rpm-md repos for different variants, which would be interesting.
Anyways until we do that, I'm definitely in favor of this as having to list things in comps and the treefile is quite painful.
I talked to Dennis about this and his concern was that it could possibly result in ostree repo that would not be reproducible from the corresponding variant. That could be avoided by adding a check in the test phase to verify this did not happen. That would give us the performance benefit while still keeping the guarantees.
Remember the "ostree" phase is really rpm-ostree where we're explicitly only taking RPMs as input, so it's not like there's some special sauce; "reproducing" is just from RPMs that are tagged in koji right?
And to rephase what I was saying in the earlier comment, we don't actually use the variants for updates anyways (right? Or do we now?).
Remember the "ostree" phase is really rpm-ostree where we're explicitly only taking RPMs as input, so it's not like there's some special sauce; "reproducing" is just from RPMs that are tagged in koji right? And to rephase what I was saying in the earlier comment, we don't actually use the variants for updates anyways (right? Or do we now?).
I don't think so. I really don't think we care much about variants for ostree, but I could be wrong.
Commit c7cc200 relates to this ticket
Commit 5c081cb relates to this ticket
Commit 660c043 relates to this ticket
Metadata Update from @onosek: - Issue tagged with: 4.1.23
Metadata Update from @onosek: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.