Bug 772622

Please extend the check for environment variable $COLLECTIONS and variable $PACKAGE as well. Or an another switch (e.g. --all) would be nice to have as well.

Rationale: 

Environment variable $COLLECTIONS will hold runtime information about which Collections are used in the test. 

If the variable is empty it should be ignored.

This would allow to modify all existing test without adding manual checks for required packages, where specific versions of scl_ packages will be known just after the test schedule.

It's not that simple, especially when collections come into play. The Makefile 'Requires:' does not need to be all installed: it only says to Beaker that is should install all packages available from the "Requires:" list. We do not have a source from where we could determine hard deps for a test. And when you run with collections, some of the Requires: stop being dependencies (because their functionality is provided by the collection. But you cannot distinguish these from proper hard deps.

In such environment, there's really nothing much we can do.

Currently I'm drafting best practices for parametrizing tests so
that they are executable against different package / component and
even software collections. The draft suggests the following three
special environment variables to be defined:

PACKAGES
    Space separated list of packages to be tested. Should this
    obsolete/extend the "RunFor" from Makefile? 

COLLECTIONS
    List of software collections to be enabled on the system.

REQUIRES
    Space separated list of packages which need to be installed.
    This should not contain any package from PACKAGES. Should this
    obsolete/extend the "Requires" from Makefile? 

    Recently, an additional syntax has been suggested for
    providing packages which must not be installed on the system,
    these would be prefixed with an exclamation mark. For example
    to have php53 dual package installed which conflicts with
    system php one would use REQUIRES="!php php53"

Now, the idea is that the "rlAssertRpm --all" command could do
something like this:

    for package in $PACKAGES $REQUIRES $COLLECTIONS; do
        rlAssertRpm $package
    done

The implementation should be quite straightforward and it would
save common setup steps. Would that be acceptable for BeakerLib?

Or, another option came to my mind: What about having a BeakerLib
function, say rlPreparePackages, which would ensure that required
packages are installed. That could mean both removing/installing
packages using 'yum remove/install' respectively plus asserting.
The required package list would be based upon the variables
mentioned in comment #4.

Thoughts?

The approach in comment 4 is OK, if the convention is adopted beyond BaseOs group. If the confusion with the different sets of possible Requires/RunFors is solved earlier and the test is guaranteed to get consistent sets, thats OK with me.

I'm not OK with Comment 5, however. Preparing the required environment (packages installed) was always the job of the harness. I'm not willing to pick up the functionality and the maintenance of this piece.

Martin will take care of the implementation.

Thinking more about the implementation reminded me suddenly of and
old coding style rule about asserts inside asserts:

    https://fedorahosted.org/beakerlib/wiki/CodingStyle#UsingrlAssertsinrlAsserts

However, for this case I guess using rlAssertRpm is acceptable as
it would produce list of asserts for individual packages which is
exactly what we want.

(In reply to comment #8)

> However, for this case I guess using rlAssertRpm is acceptable as
> it would produce list of asserts for individual packages which is
> exactly what we want.
Hmm, I think I prefer one assert for all the requires. And either list the per-package details via log messages or include the list of packages failing the tests in the assert message itself.

But I don't have a strong opinion about this, the worst that can happen is setup logs will be huge, full of rpm asserts.

proposed patch attached to BZ#910757
https://bugzilla.redhat.com/attachment.cgi?id=697868&action=diff

patch containing tests for the new functionality was attached to BZ#910757
https://bugzilla.redhat.com/attachment.cgi?id=699387&action=diff

Modified the fix. Proposed patches are:
https://bugzilla.redhat.com/attachment.cgi?id=699498&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=699499&action=diff

Proposed patches have been changed and merged in:
https://bugzilla.redhat.com/attachment.cgi?id=700562&action=diff

I've just tried patc from comment #13 applied on beakerlib-1.6-1.el6eso.noarch and it works as explained in the comment #4. 

Just a minor documentation proposal:
"Check all packages listed in the $PACKAGES $REQUIRES $COLLECTIONS" doesn't seem right for me as this function is actually asserting them.

Patch with fixed documentation attached to BZ#910757:
https://bugzilla.redhat.com/attachment.cgi?id=702794&action=diff

Both the functionality and the documentation is good from my POV.

This has not been yet committed to the git repo, moving to ASSIGNED.
https://fedorahosted.org/beakerlib/wiki/CodingStyle#BugzillaStates
Petr, could you have a look at this? It's blocking parametrization.

YAPP (yet another proposed patch) attached to BZ#910757:
https://bugzilla.redhat.com/attachment.cgi?id=704988&action=diff

Thanks for the patch, Martin. Pushed to git:
http://git.fedorahosted.org/cgit/beakerlib.git/commit/?id=f4163cb

"package" variable in proposed patch should be defined as local to avoid conflicts with variable using the same name in particular test.

Thanks, Braňo! Fix pushed to git master branch:
http://git.fedorahosted.org/cgit/beakerlib.git/commit/?id=75f6da9

*** Bug 534026 has been marked as a duplicate of this bug. ***

beakerlib-1.7-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/beakerlib-1.7-1.fc19

Package beakerlib-1.7-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing beakerlib-1.7-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7067/beakerlib-1.7-1.fc19
then log in and leave karma (feedback).

beakerlib-1.7-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.