This change would need to be made in the buildinstall phase (that is the only place calling lorax). However, as far as I can tell from the code, lorax is actually called once per architecture, and variants are not even considered at this point. Should this be refactored to run lorax for each variant separately?

Anyway, the main problem with this part of the code base is that there are no tests and no documentation on how to actually run the buildinstall phase.

This change would need to be made in the buildinstall phase (that is the only place calling lorax). However, as far as I can tell from the code, lorax is actually called once per architecture, and variants are not even considered at this point. Should this be refactored to run lorax for each variant separately?
Anyway, the main problem with this part of the code base is that there are no tests and no documentation on how to actually run the buildinstall phase.

Yes we will need to change things to run lorax once per variant when the variant is supposed to be installable.

Yes we will need to change things to run lorax once per variant when the variant is supposed to be installable.

As for whether variant is installable, is this information available somewhere already or do we need to define it in variants xml as well? Do you have some example of a variant that is not installable?

I have opened pull request #84 with initial implementation. The changes are split in multiple commits so they can be followed easily.

In a nutshell, the changes are this:

• It is possible to specify any number of packages in variants XML file.
• When lorax is run, the packages are passed to it via command line arguments.
• Lorax is not called once for each arch, but once per variant per architecture. Only variants with type variant are considered (no addons, optionals, layered products).

I have no idea if this is the right thing.

A couple questions:

• Should lorax be called with the --variant argument? The patch does so, but lorax help is not very verbose on what that option actually does.
• Is the variant filtering correct?
• As a side-effect of going through the variants, if arch does not have any such variant, lorax will not be called at all. This is different to what happened before. Can this even happen?
• Lorax is run with output dir set to work/arch/buildinstall for all variants on that arch. Should this be changed? I guess having multiple instances of lorax work with the same output at the same time will break.

• lorax --product=Fedora --version=24 --release=24 --source=file:///mnt/koji/compose/rawhide/Fedora-24-20151204.n.2/work/x86_64/repo --variant=Workstation --nomacboot --noupgrade --buildarch=x86_64 '--volid=Fedora-24 x86_64' --installpkgs=fedora-productimg-workstation /mnt/koji/compose/rawhide/Fedora-24-20151204.n.2/work/x86_64/buildinstall
  usage: lorax [-h] -p PRODUCT -v VERSION -r RELEASE [-s REPOSITORY]
  [--repo REPOSITORY] [-m REPOSITORY] [-t VARIANT] [-b URL]
  [--isfinal] [-c CONFIGFILE] [--proxy HOST] [-i PACKAGE]
  [--buildarch ARCH] [--volid VOLID] [--macboot] [--nomacboot]
  [--noupgrade] [--logfile LOGFILE] [--tmp TMP]
  [--cachedir CACHEDIR] [--workdir WORKDIR] [--force]
  [--add-template ADD_TEMPLATES]
  [--add-template-var ADD_TEMPLATE_VARS]
  [--add-arch-template ADD_ARCH_TEMPLATES]
  [--add-arch-template-var ADD_ARCH_TEMPLATE_VARS] [--noverify]
  [--sharedir SHAREDIR] [--enablerepo [repo]]
  [--disablerepo [repo]] [-V]
  OUTPUTDIR
  lorax: error: output directory /mnt/koji/compose/rawhide/Fedora-24-20151204.n.2/work/x86_64/buildinstall should not exist.

workstation variant for instance we would pass "--variant Workstation"

This should fix the problem with output directories. The --variant argument is already used.