tests: update packages to keep ceph common and libraries in sync #510
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
Sometimes the version in the RPM repository don't match the version of the base image. This change updates the packages before installing the libraries in order to make them match. Signed-off-by: Sven Anderson <sven@redhat.com>
nixpanic
approved these changes
May 31, 2021
leseb
reviewed
May 31, 2021
Member
leseb
left a comment
There was a problem hiding this comment.
nit in the commit message: the version in the RPM repository don't match. s/don't/doesn't
Collaborator
Author
Right, but I will just leave it like that so we don't have to restart the tests. I guess you agree. ;-) |
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
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.
Sometimes the version in the RPM repository don't match the version
of the base image. This change updates the packages before installing
the libraries in order to make them match.
Signed-off-by: Sven Anderson sven@redhat.com