Hide Forgot
Description of problem: Currently, the test owner has two option to specify test's requirements: (1) 'Requires:' which are soft requirements. They are consumed by Beaker and transferred to Anaconda in the kickstart file. If the required package is not available during a kickstart, it will not be installed. Therefore, I call it soft-requirements. We have to note here, that there are cases where package is not present in a kickstart tree, but it is present in the repository after the kickstart. Example is rhn-setup in Fedora-14. (2) 'RhtsRequires' are hard-requires. They are transformed directly to the rpm-requires of test rpm. There are two problems with that: (A) 'RhtsRequires' does not allow you to specify different requirement for different releases similar to the spcefiles. Example: %if 0%{?rhel} && 0%{?rhel} <= 5 Requires: yum-security %else Requires: yum-plugin-security %if (B) 'RhtsRequires' does not allow you to specify required version of a package --- Test Authors have to solve it on their own: (A) for pkg in $required_packages; do rpm -q $pkg || rlRun "yum install -y $pkg" rlAssertRpm $pkg done (B) fixed_in='1000200020004' version=`rpm -q --qf '%{version}.%{release}\n' \ --whatprovides XYZ \ | perl -pe 's!\.(\d+)!sprintf "%04d", $1!ge' \ | awk -F. '{print $1}'` [ $version -gt $fixed_in ]
I forget to mention one fact. Test are often installed manually on beaker machines by developers or QA, thus the kickstart-way does not work.
Hello Šimon, Yes, the Requires is a soft requires which only passes a list to anaconda. This has worked but is not ideal. I'd like to move away from installing any test/task required packages during install. The RhtsRequires is a hard requires like you mention. It simply puts the requires into the test/task rpm. We could fix the version problem since rpms support that. But we wouldn't be able to support the multiple requires based on the release. (the example you give would mean we would need to build the rpms for each release and that won't scale) Going forward this is how I think it may work: 1 - Do not install packages during initial install. 2 - Drop RhtsRequires 3 - Whatever installs the task/test will inspect the package for what additional packages need to be installed. 4 - The list of packages to be installed could be a simple test file. With additional text files to handle release specific requires. 5 - Since this package list should be accurate for a specific release we should report a warn or fail when we can't install the requirements and not run the test/task 6 - This should not be dependent on the process that installs the task/test (meaning, it should not require rpm or yum, since we will want to support other containers and install methods) 7 - This only deals with rpm packages currently (notice the files are prepended with Rpm. We could support DebPackages or WinPackages?) RpmPackages: yum-security httpd >= 2 # Support versioning (since this is RpmPackages we can # use rpmutils to do the versioning?) RpmPackages.$releasever: ($releasever may expand to 5Server or 5Client) -yum-security # remove yum-security that we inherited from RpmPackages --PackageKit # don't just remove from the list of packages to install, but # make sure this package is not installed before doing the # testing. (yum remove $PACKAGE) don't fail if package not # installed. yum-plugin-security # add our release specific entry This would allow for testing to act the same when run manually and when run inside the beaker automated infrastructure. Thoughts?
Hello Bill, I have a comment. I would discourage you to drop RhtsRequires. They seems quite essential to me. Rpm has a dependencies and their resolution in its nature. Why not leverage that? Why to reinvent the wheel? Is there so many problems supporting RhtsRequires? In the Satellite team, I can grep about 162 tests with RhtsRequires defined. The RhtsRequires has great thing, because I can login with an arbitrary machine and install test rpm by rpm -Uvh. I am afraid to loose this option with point (3) from your last comment.
Hi Simon, IIUC it's just the opposite. The goal is to give test better control over the environment: what get's installed and what uninstalled if have to be. Right now 'make run' completely ignores Requires and you have to install these packages manually. The feature 'make run' *attempts* to get everything needed and to check it will be kept.
+1. It seems cool to check requirements before each test run automatically, not just during the installation. On the other hand does it mean, that 'make run' will have potential remove f.e whole desktop?
(In reply to comment #5) > +1. It seems cool to check requirements before each test run automatically, > not just during the installation. On the other hand does it mean, that > 'make run' will have potential remove f.e whole desktop? That is a possibility. But I would only suggest running tests on a test machine anyway. I wouldn't run any of these on my actual desktop machine. Even when developing a test I typically develop in a chroot or on another machine. While not strictly a requirement here, we would like to get away from using rpm as a task/test delivery mechanism. We are investigating URI's like http://path/to/tarball, git://location/in/git, etc.. Hope this makes sense.
Bulk reassignment of issues as Bill has moved to another team.
restraint supports this now