Some of the package names were changed from "{name}" to
"{version}-{name}" without changing their requirements. Let's fix it
here.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Mock complains about several files being installed, but not part of the
rpm. These files are copied and generated when selftesting the Avocado.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

On Python 2 packages.  We were previously relying on the fact that
stevedore requires six too, but that's not the right way to approach a
direct dependency.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The Python dependencies are already tracked by the python2 or python3
"Requires".  This filters out the python binaries from the RPM
automatic requires/provides scanner.

Before this change, a query for the requirements of the Python 2 package
would reveal:

    $ rpm -qRp fedora-26-noarch/python2-avocado-60.0-1.fc26.noarch.rpm
    /usr/bin/python2
    /usr/bin/python3
    ...

Reference: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Filtering_provides_and_requires_after_scanningSigned-off-by: NCleber Rosa <crosa@redhat.com>

So that, if the system version on a given distro is Python 3, the
python3-avocado package will automatically "Provide:" python-avocado.

Reference: https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macroSigned-off-by: NCleber Rosa <crosa@redhat.com>

As it has been done with python-avocado-common in 18d21873,
the requirements should really be in the versioned sub-packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Into the specific python2-avocado or python3-avocado.  This is the
right way, and not using the python-avocado package that won't get
installed, to make sure the needed configuration files are always
present.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

This adds Python 3 packages for Avocado and for all plugins that have
its dependencies fulfilled by Python 3 versions of their requirements.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

And favor a system wide path for `avocado exec-path`, in the same way
we prefer the `/etc/avocado` files.  If not running from packages, the
Python version specific location will be used.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

With content that is common to both Python 2 and Python 3 versions of
the Avocado packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Commit 24f3b936 removed compatibility with package name "avocado", but
missed that for plugins.  Let's remove those too.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Both branches of the conditional includes distros we build packages
for.  So, it's safe to use that "naked" build requirement.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

We currently build on EL7, Fedora 26 and Fedora 27.

On EL7, some of the Python packages are prefixed with "python2", and
some others are not.  We have been previously using the name of
"Provides" instead of the real package names.

Now, Python package names on Fedora 26 and Fedora 27 are the same for
those we depend on.

This adds a conditional block for EL7, and another one for Fedora 26
and 27.  Some Python packages have been kept on both blocks, in
preparation for the Python 3 packaging that will happen only for the
Fedora packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The package is named PyYAML on EL7, so let's use the correct name, and
not the name of "Provides" tag.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

We don't build on Fedora 24 anymore, so let's remove this hack.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

It's about time we stop providing support for "avocado".  The other
package the project ships, "avocado-plugins-vt" (also badly named)
uses python-avocado as a requirement name.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Unless a lower version is set as a requirement, the RPM building
process will attempt to download from PyPI, which is not allowed.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

With the recent changes the "libexec" dir is only available when
installed via RPM. In order to have "libexec" files available
as standard package we have to include it in  the package_files
dir (avocado/). The benefit is that we can actually use package
resources to get the location in "avocado exec-path" command.

For packaging purposes let's simply symlink $libexec/avocado to the
packaged $avocado/libexec location so there is the usual location, but
keep using the python-location by default.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

To remove some of the bloat (even if little) of the base
python-avocado package, let's move content that is not useful to
Python developers out of the way.

This should also make the experience of content more similar across
users of the Python module (say, from a `pip install`) and users of
the python-avocado package.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There's little to no point in providing these files, since the
generated man pages are already packaged.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Leaving them only in the source distribution generation (if one runs
python setup.py sdist) and in the "example" RPM package.

Because the copying of those files won't be performed by the Python
module installation code, it must be done in the SPEC file.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

These files weren't being installed by the setup.py code, and thus
ended up missing from RPM packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

In a pure Python world[1] the "avocado" module requires the existence
of these configuration files.  Let's make those configuration files
"data files" of that module.

Since the configuration location can now be a different, the settings
module needs adjustments to also attempt to load them from package
resources (which is tied to the data files).

Finally, when using RPM packages, we need to put the configuration
back into the system location (/etc).

[1] - that is, ignoring operating system or distribution specific
      conventions and packaging technologies
Signed-off-by: NCleber Rosa <crosa@redhat.com>

So there are no clases in history of RPM releases.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

This builds a new sub package for this new optional plugin.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

PICT is a free software (MIT licensed) tool that implements
combinatorial testing.  Information about it can be found here:

   https://github.com/Microsoft/pict/

This is a very simple, but functional varianter implementation.  It
performs the basic tasks of creating variants and making parameters
accessible to tests.  To test this version, it's recommended to
download PICT, build it (it only takes a C compiler such as GCC or
clang and make) and put it in a location included in your PATH (or use
`--pict-binary`).

To list the variants generated with the default order (2, that is,
do a pairwise idenpendent combinatorial testing):

 $ avocado variants --pict-parameter-file=examples/params.pict
 Pict Variants (11):
 Variant amd-scsi-rtl8139-windows-rhel6-acff:    /run
 ...
 Variant amd-ide-e1000-linux-rhel6-eb43:    /run

To list the variants generated with a 3-way combination:

 $ avocado variants --pict-parameter-file=examples/params.pict \
   --pict-order-of-combinations=3

 Pict Variants (28):
 Variant intel-ide-virtio-windows-rhel7-aea5:    /run
 ...
 Variant intel-scsi-e1000-linux-rhel7-9f61:    /run

It's also possible to run tests with variants generated by the same
command line switches.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Let's also package and build the recently introduced golang plugin.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There's a problem with the current SPEC file in that it doesn't
exclude some of the files part of the "plugins-loader-yaml" package.

This would cause problems if that plugin package attempts to be
installed, causing conflicts because they're packaged on two packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This commit revomes flexmock from the various requirements file, from
the RPM SPEC file.  Starting here, it's officially no longer an
Avocado dependency.
Signed-off-by: NCleber Rosa <crosa@redhat.com>