-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
package layering: split versions between OSTree base vs yum repo #400
Comments
Feels like a dup of #401 |
This is the culmination of a lot of work to make package layering more reliable. This archive repo provides all packages that have ever been in the updates repository, which means there should always be a solution that will depsolve given the existing set of base layer packages. Pairing this along with coreos/rpm-ostree#2125 means that we should finally see less of the split base layer vs update repo problem and see less `Forbidden base package replacements` errors. Fixes: coreos/fedora-coreos-tracker#400
This is the culmination of a lot of work to make package layering more reliable. This archive repo provides all packages that have ever been in the updates repository, which means there should always be a solution that will depsolve given the existing set of base layer packages. Pairing this along with coreos/rpm-ostree#2125 means that we should finally see less of the split base layer vs update repo problem and see less `Forbidden base package replacements` errors. Fixes: coreos/fedora-coreos-tracker#400
This is pretty much done now. It's hitting
The idea is that you continue to do what you were doing in the past and from the next set of releases and on you should hopefully never hit the |
This is the culmination of a lot of work to make package layering more reliable. This archive repo provides all packages that have ever been in the updates repository, which means there should always be a solution that will depsolve given the existing set of base layer packages. Pairing this along with coreos/rpm-ostree#2125 means that we should finally see less of the split base layer vs update repo problem and see less `Forbidden base package replacements` errors. Fixes: coreos/fedora-coreos-tracker#400
The fix for this went into testing stream release |
The fix for this went into stable stream release |
This is the culmination of a lot of work to make package layering more reliable. This archive repo provides all packages that have ever been in the updates repository, which means there should always be a solution that will depsolve given the existing set of base layer packages. Pairing this along with coreos/rpm-ostree#2125 means that we should finally see less of the split base layer vs update repo problem and see less `Forbidden base package replacements` errors. For context see coreos/fedora-coreos-tracker#400 (cherry picked from commit 5ee6bce)
This is the culmination of a lot of work to make package layering more reliable. This archive repo provides all packages that have ever been in the updates repository, which means there should always be a solution that will depsolve given the existing set of base layer packages. Pairing this along with coreos/rpm-ostree#2125 means that we should finally see less of the split base layer vs update repo problem and see less `Forbidden base package replacements` errors. Fixes: coreos/fedora-coreos-tracker#400
This is the culmination of a lot of work to make package layering more reliable. This archive repo provides all packages that have ever been in the updates repository, which means there should always be a solution that will depsolve given the existing set of base layer packages. Pairing this along with coreos/rpm-ostree#2125 means that we should finally see less of the split base layer vs update repo problem and see less `Forbidden base package replacements` errors. For context see coreos/fedora-coreos-tracker#400
- because update repos is enabled by default rpm-ostree install tries to upgrade selinux packages as dependency. There is a huge mess around, see also coreos/fedora-coreos-tracker#400 - workaround for installation of fix version of cri-o: disable vars, so we can overwrite them in inventory.
This is a problem that periodically plagued the Atomic Host community, periodically does plague the Silverblue community and is starting to creep into FCOS as users attempt to package layer rpms that aren't included in the base. The user attempts a package layering operation that fails because the versions of packages in the base OS are out of sync with the versions in the yum repositories. There is also an issue against the RPM-OSTree repo for this problem, but it's a high level problem and a solution will probably take some coordination at multiple levels so we're creating a new ticket here to track that coordination.
The user ends up with an error like:
We need to coordinate with Fedora releng, Fedora Silverblue working group, and the RPM-OSTree maintainers, in order to try to come up with a better solution to this problem. @owtaylor from the Silverblue team did a nice writeup on the problem last year in this public google document, so there is much more context about the problem and possible solutions in there.
The text was updated successfully, but these errors were encountered: