Test #4158
Updated by ttereshc about 6 years ago
h3. Ingredients
* consumer
* consumer profile
It used to be of @rpm@ type only, now there can be a second active profile for the same consumer, "modulemd" type.
So two types are of consumer profiles are now allowed for uploading. Their format is different depending on type but it's not tested validated anywhere, so don't test with different weird fields in the profile :) See examples and expected format in #3927.
* repository with modular content, like "our fixtures":https://repos.fedorapeople.org/pulp/pulp/fixtures/rpm-with-modules/
Applicability calculates which RPMs, modules and errata are applicable.
h3. Conditions when each of the content types are applicable
1. RPM is applicable:
* in case of modular RPM:
* if its corresponding module is enabled
* if the first-level module dependencies of that module are enabled
* if that RPM is newer than the installed one
* in case of non-modular RPM:
* if RPM name doesn't match the name of any of the modular RPMs from enabled modules
* if that RPM is newer than the installed one
2. Module is applicable:
* if at least one RPM which is referred in its artifacts is present in a repo
* if at least one RPM which is referred in its artifacts is applicable
3. Erratum is applicable:
* if at least one RPM which is referred in the erratum pkglist is present in a repo
* if at least one RPM which is referred in the erratum pkglist is applicable
h3. Behavioral changes
* It was required to request consumer applicability first (to create an applicability profile) and only then it was possible to update it with repo applicability. It's no longer a requirement, repo applicability will create applicability profiles if they don't exist.
h3. Suggested tests (for fixtures repo)
* Test applicability when only modular RPMs are installed on a consumer
* Test applicability when modular and non-modular RPMs are installed on a consumer
* Test applicability when enabled module has module dependencies (see @duck@ modules)
* Test applicability when enabled module has multiple versions, the same stream but multiple versions (see duck and kangaroo)
* Test applicability when no modules are enabled
* Test applicability when module is present in an erratum
* Test applicability when module is absent from an erratum but still applicable (see @walrus@ modules)
* Test applicability when a non-modular erratum refers to an RPM with the same name as modular applicable RPM (see @walrus@ RPM and @Sea_Erratum@)
* any other useful scenarios
.