Skip to content

[next-devel] lockfiles: remove for now#351

Merged
jlebon merged 1 commit intocoreos:next-develfrom
jlebon:pr/drop-lockfiles
Apr 15, 2020
Merged

[next-devel] lockfiles: remove for now#351
jlebon merged 1 commit intocoreos:next-develfrom
jlebon:pr/drop-lockfiles

Conversation

@jlebon
Copy link
Copy Markdown
Member

@jlebon jlebon commented Apr 15, 2020

F32 is more or less frozen right now. And it'd be really nice if we had
something f32-based in time for the f32 release. So let's just drop
all the lockfiles for now so we can do an unlocked build and avoid all
the issues that are still being fixed.

Our overrides should all already be in the pool, and since they're still
the highest NEVRA, they still get picked.

F32 is more or less frozen right now. And it'd be really nice if we had
*something* f32-based in time for the f32 release. So let's just drop
all the lockfiles for now so we can do an unlocked build and avoid all
the issues that are still being fixed.

Our overrides should all already be in the pool, and since they're still
the highest NEVRA, they still get picked.
@jlebon
Copy link
Copy Markdown
Member Author

jlebon commented Apr 15, 2020

Requires: coreos/coreos-assembler#1352

Copy link
Copy Markdown
Member

@dustymabe dustymabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bgilbert
Copy link
Copy Markdown
Contributor

For the record, what issues does this address that couldn't be fixed by bumping the lockfiles to the NEVRAs that an unlocked build would have picked anyway?

@jlebon
Copy link
Copy Markdown
Member Author

jlebon commented Apr 15, 2020

For the record, what issues does this address that couldn't be fixed by bumping the lockfiles to the NEVRAs that an unlocked build would have picked anyway?

Basically cosa today will automatically try to enforce lockfiles if they're present in the repo. But we also don't want to tag packages into the pool because of coreos/fedora-coreos-tracker#454. Which means that if we have a lockfile, there's no guarantee that we'll be able to actually perform that build in the pipeline. So for now, we're just banking on the fact that f32 doesn't change much anyway and that CI will give us coverage.

Anyway, this is all super messy and there's different ways to do this, but the bottom line is this is a temporary hack until we get the rpm-ostree lockfile patches in (coreos/rpm-ostree#1858 and coreos/rpm-ostree#2058).

Anyway, now that coreos/coreos-assembler#1352 has merged, I restarted CI here to make sure we're green before merging!

jlebon added a commit to jlebon/fedora-coreos-pipeline that referenced this pull request Apr 15, 2020
We should be able to rebuild this stream soon after
coreos/fedora-coreos-config#351 merges.
@jlebon jlebon merged commit 213b52c into coreos:next-devel Apr 15, 2020
@jlebon jlebon deleted the pr/drop-lockfiles branch April 15, 2020 22:03
jlebon added a commit to coreos/fedora-coreos-pipeline that referenced this pull request Apr 15, 2020
We should be able to rebuild this stream soon after
coreos/fedora-coreos-config#351 merges.
jlebon added a commit to jlebon/fedora-coreos-releng-automation that referenced this pull request Apr 16, 2020
As per coreos/fedora-coreos-config#351.

Otherwise, it's (quite rightly) not happy to use the "unlocked"
semantics for versioning.

This will automatically error out again once we add lockfiles back in,
so we'll definitely not forget to drop this hack.
@jlebon
Copy link
Copy Markdown
Member Author

jlebon commented Apr 30, 2020

For posterity, note lockfiles were added back in #370.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants