On 2/4/20 06:20, Kamil Paral wrote:
On Mon, Feb 3, 2020 at 3:48 PM pmkellly@frontier.com pmkellly@frontier.com wrote:
This proposal is for changes to Base test case: "QA:Testcase package install remove" The existing test case is here:
https://fedoraproject.org/wiki/QA:Testcase_package_install_remove
Though there is a requirement to install packages, there are no commands provided to accomplish this.
The process doesn't need to involve command. The purpose of the test case is to test any package manager, including graphical ones. So for Workstation, we test it with gnome-software. For KDE, we test it with both graphical managers they have in there (because KDE). On Server, we test it with dnf.
There are certainly advantages of being non-specific. You get several package managers tested and likely with several ways of using the package manager. I'm sure someone would install their favorite package manager then run the test.
Also, there are no instructions concerning things to look for during the installations.
If we specified the packages to install, we could test an RPM package and a Modular package. I don't think dnf can handle Flatpacks.
Modularity has a separate list of test cases, see e.g. here: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_B...
Modularity is part of all of the Fedora composes; is it not? I'm curious why these aren't in the Base cases. Though from what I've seen, there aren't a lot of modules available yet. Is it just because modularity is sort of just getting started. I admit modularity had been off my radar until the Eclipse problem.
We have no test cases for flatpaks, at the moment.
Another one that's just getting started. Though I do have two flatpacks as part of my standard "as deployed" configuration.
This test case uses the command line: (rpm -q package1 package2) This is done twice; once to remove the packages and once to verify the removal.
I might be good to change the first one to: (dnf remove). Though we could use this command again to verify the removal, it might be more revealing to use (dnf info). The DNF info will show, among other things, "Installed" or "Available".
If we want to test dnf, we need to verify the operation with something else, not dnf itself. Rpm is the lowest tool we can use for verification.
Your point is well made. However, since we are letting the testers use their package manager of choice, I would suggest we remove the rpm commands and just instruct them to remove the packages they installed and verify they have been removed.
There is one last point I was thinking of. Though I have never dug into a package manager. I imagine they have some basic test to see that they have installed a package. I'm not sure this is good enough to say that the package actually got installed so that it would work. Perhaps it would be worthwhile to specify one of the two packages (something simple) so the test could also start the application just to see that it would start.
As for removing packages, That's problematic. I know a lot depends on the actual package being removed, but there is always trash left behind. Sometimes other things get broken. As in one of the blocker bugs yesterday. I'm thinking that the only practical test for package removal is that the system still boots and isn't otherwise broken.
Now... This discussion is why I sent the email before just starting on a draft of a modified test case.
Have a Great Day!
Pat (tablepc)