containers: work around protobuf package issues #1038
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Work around errors related to protobuf package locations on centos. This is triggered by our squid jobs failing with errors like: ``` 22.40 Problem: protobuf-3.14.0-13.el9.i686 from appstream does not belong to a distupgrade repository 22.40 - package protobuf-compiler-3.14.0-13.el9.x86_64 from @System requires protobuf = 3.14.0-13.el9, but none of the providers can be installed 22.40 - cannot install both protobuf-3.14.0-14.el9.x86_64 from appstream and protobuf-3.14.0-13.el9.x86_64 from @System 22.40 - cannot install both protobuf-3.14.0-14.el9.x86_64 from appstream and protobuf-3.14.0-13.el9.x86_64 from appstream 22.40 - cannot install the best update candidate for package protobuf-3.14.0-13.el9.x86_64 22.40 - problem with installed package protobuf-compiler-3.14.0-13.el9.x86_64 22.40 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ------ ``` Signed-off-by: John Mulligan <jmulligan@redhat.com>
ca24949 to
42c7c75
Compare
Collaborator
Author
|
@anoopcs9 - I added a workaround for the squid protobof changes. I had to tweak things a little to get it working on the centos8 images we still have (octopus, pacific, quincy) in the CI. |
5 tasks
anoopcs9
approved these changes
Oct 23, 2024
Collaborator
anoopcs9
left a comment
There was a problem hiding this comment.
I'm hopeful that we get a new squid image with updated packages so that this workaround won't last much longer.
anoopcs9
added a commit
to anoopcs9/go-ceph
that referenced
this pull request
Nov 7, 2024
In general it is not a best practice to blindly update packages as a whole while building another from a base container image. Historically this step was required due to the introduction of version specific installation[1] of packages i.e, we extract the package version that comes with the base container image and try to install the matching development libraries which might be unavailable close to a new release happening in upstream. In order to overcome this short gap we came up with the idea of `yum update`[2] to fetch whatever is the latest and then extract the version for further installation of development libraries. This seemed to work until we discovered a different issue where updated versions for particular dependencies are pushed to standard repositories causing problems[3] during `yum update`. Ceph repositories(and packages) are now more robust and DNF is capable of handling such situations to figure out the new/updated versions for packages even if a match is not found with the already installed package versions. Ideally it can never be the case that matching packages for each version are missing from a particular repository directory(only the links to the directories is supposed to change). Thus in our best interest we avoid running `yum update`. [1] ceph#331 [2] ceph#510 [3] ceph#1038 Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
phlogistonjohn
pushed a commit
to anoopcs9/go-ceph
that referenced
this pull request
Nov 12, 2024
In general it is not a best practice to blindly update packages as a whole while building another from a base container image. Historically this step was required due to the introduction of version specific installation[1] of packages i.e, we extract the package version that comes with the base container image and try to install the matching development libraries which might be unavailable close to a new release happening in upstream. In order to overcome this short gap we came up with the idea of `yum update`[2] to fetch whatever is the latest and then extract the version for further installation of development libraries. This seemed to work until we discovered a different issue where updated versions for particular dependencies are pushed to standard repositories causing problems[3] during `yum update`. Ceph repositories(and packages) are now more robust and DNF is capable of handling such situations to figure out the new/updated versions for packages even if a match is not found with the already installed package versions. Ideally it can never be the case that matching packages for each version are missing from a particular repository directory(only the links to the directories is supposed to change). Thus in our best interest we avoid running `yum update`. [1] ceph#331 [2] ceph#510 [3] ceph#1038 Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
anoopcs9
added a commit
to anoopcs9/go-ceph
that referenced
this pull request
Nov 26, 2024
In general it is not a best practice to blindly update packages as a whole while building another from a base container image. Historically this step was required due to the introduction of version specific installation[1] of packages i.e, we extract the package version that comes with the base container image and try to install the matching development libraries which might be unavailable close to a new release happening in upstream. In order to overcome this short gap we came up with the idea of `yum update`[2] to fetch whatever is the latest and then extract the version for further installation of development libraries. This seemed to work until we discovered a different issue where updated versions for particular dependencies are pushed to standard repositories causing problems[3] during `yum update`. Ceph repositories(and packages) are now more robust and DNF is capable of handling such situations to figure out the new/updated versions for packages even if a match is not found with the already installed package versions. Ideally it can never be the case that matching packages for each version are missing from a particular repository directory(only the links to the directories is supposed to change). Thus in our best interest we avoid running `yum update`. [1] ceph#331 [2] ceph#510 [3] ceph#1038 Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
anoopcs9
added a commit
to anoopcs9/go-ceph
that referenced
this pull request
Nov 27, 2024
In general it is not desirable to blindly update packages as a whole while building another from a base container image. Historically this step was required due to the introduction of version specific installation[1] of packages i.e, we extract the package version that comes with the base container image and try to install the matching development libraries which might be unavailable close to a new release happening in upstream. In order to overcome this short gap we came up with the idea of `yum update`[2] to fetch whatever is the latest and then extract the version for further installation of development libraries. This seemed to work until we discovered a different issue where updated versions for particular dependencies are pushed to standard repositories causing problems[3] during `yum update`. Ceph repositories(and packages) are now more robust and DNF is capable of handling such situations to figure out the new/updated versions for packages even if a match is not found with the already installed package versions. Ideally it can never be the case that matching packages for each version are missing from a particular repository directory(only the links to the directories is supposed to change). Thus in our best interest we avoid running `yum update`. [1] ceph#331 [2] ceph#510 [3] ceph#1038 Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
phlogistonjohn
pushed a commit
to anoopcs9/go-ceph
that referenced
this pull request
Dec 11, 2024
In general it is not desirable to blindly update packages as a whole while building another from a base container image. Historically this step was required due to the introduction of version specific installation[1] of packages i.e, we extract the package version that comes with the base container image and try to install the matching development libraries which might be unavailable close to a new release happening in upstream. In order to overcome this short gap we came up with the idea of `yum update`[2] to fetch whatever is the latest and then extract the version for further installation of development libraries. This seemed to work until we discovered a different issue where updated versions for particular dependencies are pushed to standard repositories causing problems[3] during `yum update`. Ceph repositories(and packages) are now more robust and DNF is capable of handling such situations to figure out the new/updated versions for packages even if a match is not found with the already installed package versions. Ideally it can never be the case that matching packages for each version are missing from a particular repository directory(only the links to the directories is supposed to change). Thus in our best interest we avoid running `yum update`. [1] ceph#331 [2] ceph#510 [3] ceph#1038 Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
phlogistonjohn
pushed a commit
to phlogistonjohn/go-ceph
that referenced
this pull request
Dec 11, 2024
In general it is not desirable to blindly update packages as a whole while building another from a base container image. Historically this step was required due to the introduction of version specific installation[1] of packages i.e, we extract the package version that comes with the base container image and try to install the matching development libraries which might be unavailable close to a new release happening in upstream. In order to overcome this short gap we came up with the idea of `yum update`[2] to fetch whatever is the latest and then extract the version for further installation of development libraries. This seemed to work until we discovered a different issue where updated versions for particular dependencies are pushed to standard repositories causing problems[3] during `yum update`. Ceph repositories(and packages) are now more robust and DNF is capable of handling such situations to figure out the new/updated versions for packages even if a match is not found with the already installed package versions. Ideally it can never be the case that matching packages for each version are missing from a particular repository directory(only the links to the directories is supposed to change). Thus in our best interest we avoid running `yum update`. [1] ceph#331 [2] ceph#510 [3] ceph#1038 Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
mergify bot
pushed a commit
that referenced
this pull request
Dec 16, 2024
In general it is not desirable to blindly update packages as a whole while building another from a base container image. Historically this step was required due to the introduction of version specific installation[1] of packages i.e, we extract the package version that comes with the base container image and try to install the matching development libraries which might be unavailable close to a new release happening in upstream. In order to overcome this short gap we came up with the idea of `yum update`[2] to fetch whatever is the latest and then extract the version for further installation of development libraries. This seemed to work until we discovered a different issue where updated versions for particular dependencies are pushed to standard repositories causing problems[3] during `yum update`. Ceph repositories(and packages) are now more robust and DNF is capable of handling such situations to figure out the new/updated versions for packages even if a match is not found with the already installed package versions. Ideally it can never be the case that matching packages for each version are missing from a particular repository directory(only the links to the directories is supposed to change). Thus in our best interest we avoid running `yum update`. [1] #331 [2] #510 [3] #1038 Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work around errors related to protobuf package locations on centos. This is triggered by our squid jobs failing with errors like:
I tested this change on both squid and reef locally and both built the ci image successfully.