get_problematic_pkgs() adds packages that it shouldn't #378
Comments
abadger
added a commit
to abadger/convert2rhel
that referenced
this issue
Nov 29, 2021
* test_find_pkg_names: Add a few more package names that represent
cornercases ("." in package name, starts with a digit, has version
numbers in the name, has uppercase characters, has an epoch.
* test_get_problematic_pkgs: Move this out of the unittest.TestCase
so that we can use pytest's parametrize functionality with it.
* Rework the test to use parametrize. Parametrize will run a separate
test for each set of assertions, that way we will (1) be able to
pinpoint which data caused the problem and (2) will test all of the
permutations of calling get_problematic_pkgs instead of failing on
the first problem and not knowing whether the other datasets passed.
* Found that the Requires dataset should be causing a test failure.
Break that into a separate test function that tests a subset of
functionality for now with comments on what is going wrong.
Opened Issue oamg#378 to address that in the future.
abadger
added a commit
to abadger/convert2rhel
that referenced
this issue
Nov 30, 2021
* Add pkg names with dots, dashes, starting with numbers, plus signs and uppercase to our tests of get_problematic_pkgs(). All of these filenames now are properly parsed for Error tests (which is what this PR focuses on fixing) but do not work when specified in a Requires. That should be addressed when oamg#378 is fixed. * Added the java-1.8.0-openjdk package to the unusual package names to check (version number with dots embedded inside of the package name)
bocekm
added a commit
that referenced
this issue
Dec 1, 2021
Fix detection of gcc-c++ and other package names.
The regular expression that was being used to parse package names out of
yum output was missing gcc-c++, NetworkManager, and other package names.
Using a simpler regex and a function that parses the package names from
the rest of the NVR should fix that.
This fixes a user visible problem where packages like gcc-c++ can cause
convert2rhel to fail to downgrade packages. This is because gcc-c++
would be missed by the regex and thus we'd be unable to figure out that
we need to downgrade gcc-c++ when downgrading gcc.
* test_find_pkg_names: Add a few more package names that represent
cornercases ("." in package name, starts with a digit, has version
numbers in the name, has uppercase characters, has an epoch).
* Found that the Requires dataset should be causing a test failure.
Break that into a separate test function that tests a subset of
functionality for now with comments on what is going wrong.
Opened Issue #378 to address that in the future.
* Add pkg names with dots, dashes, starting with numbers, plus signs and
uppercase to our tests of get_problematic_pkgs(). All of these
filenames now are properly parsed for Error tests (which is what this
PR focuses on fixing) but do not work when specified in a Requires.
That should be addressed when
#378 is fixed.
* Added the java-1.8.0-openjdk package to the unusual package names to
check (version number with dots embedded inside of the package name)
Co-authored-by: Eric Gustavsson <[email protected]>
Co-authored-by: Michal Bocek <[email protected]>
bocekm
added a commit
to mportman12/convert2rhel
that referenced
this issue
Feb 22, 2022
Fix detection of gcc-c++ and other package names.
The regular expression that was being used to parse package names out of
yum output was missing gcc-c++, NetworkManager, and other package names.
Using a simpler regex and a function that parses the package names from
the rest of the NVR should fix that.
This fixes a user visible problem where packages like gcc-c++ can cause
convert2rhel to fail to downgrade packages. This is because gcc-c++
would be missed by the regex and thus we'd be unable to figure out that
we need to downgrade gcc-c++ when downgrading gcc.
* test_find_pkg_names: Add a few more package names that represent
cornercases ("." in package name, starts with a digit, has version
numbers in the name, has uppercase characters, has an epoch).
* Found that the Requires dataset should be causing a test failure.
Break that into a separate test function that tests a subset of
functionality for now with comments on what is going wrong.
Opened Issue oamg#378 to address that in the future.
* Add pkg names with dots, dashes, starting with numbers, plus signs and
uppercase to our tests of get_problematic_pkgs(). All of these
filenames now are properly parsed for Error tests (which is what this
PR focuses on fixing) but do not work when specified in a Requires.
That should be addressed when
oamg#378 is fixed.
* Added the java-1.8.0-openjdk package to the unusual package names to
check (version number with dots embedded inside of the package name)
Co-authored-by: Eric Gustavsson <[email protected]>
Co-authored-by: Michal Bocek <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The regular expression for Requires in get_problematic_pkgs() can parse yum output incorrectly and end up adding package names that either don't exist or are different than the package which was actually specified. For instance,
python2_hawkey >= 0.7.0is parsed intopython2I'm unsure how big a problem this is in practice (In the python2-hawkey case, I believe it will just result in downgrading the python2 package unnecessarily, which will add time to the run but won't be an error) but we should look into fixing it.We can probably call either the yum or rpm apis to do so; at the command line,
rpm -q --whatprovides <REQUIRES>will give us the package name of any Requires in a package that is installed.yum whatprovides <REQUIRES>if we need to search the repositories for the provide, not just the installed packages.Once fixed, we should update the unittest to test that the output of get_problematic_pkgs() is exactly what we expect rather than merely checking that the values we expect to be there are (but not checking whether extra values are present).
The text was updated successfully, but these errors were encountered: