Approaches to installing excluded packages

[achilleas-k]

Background

We had a long-standing issue that packages on the exclude list for image types couldn't be installed if selected by the user through the blueprint.

Current solution

This was solved in #1349 for existing distros. To solve this, the Packages() method (which returns the list of packages to depsolve alongside an exclude list) iterates over the blueprint packages and removes them from the exclude list if they're found.

Limitation of current solution

One limitation of this solution is that if a dependency of a selected package is excluded, the depsolve will still fail. This is demonstrated in the regression test that was added alongside the solution
https://github.com/osbuild/osbuild-composer/blob/b5987a5ca51826f29a3bce742d693a55f16f016f/test/cases/regression-include-excluded-packages.sh#L28-L35

The redhat-lsb-core package depends on nss. nss is on the exclude list, so to install redhat-lsb-core, nss needs to be included in the blueprint.

Alternative solution

In #1536 I solved this in a different way. With the introduction of package sets we can have an arbitrary number of package sets, whereas before we were limited to build packages and the plainly named packages, which were the packages that would land in the image. The PackageSets() method (the equivalent to the old Packages() method mentioned above) now returns multiple package sets (each set consisting of an include and an exclude list), including a package set labelled blueprint, which includes the packages specified in the blueprint. This package set is depsolved separately from the main package set and so isn't affected by the exclusion list from the image type definition.

This overcomes the limitation of the previous solution. The separate depsolving means that blueprint packages are unrestricted. When writing the pipeline, the two package lists are merged to be installed in the image. Duplicates (which are expected) cause no issues when building.

Limitations of alternative solution

The alternative solution introduces a different problem. Since we depsolve two package sets then merge them, it introduces the possibility of conflicting packages being selected. I suspect that this issue is much rarer than the issue with the previous solution however, so I think it's preferable.

The Kernel issue

A related issue showed up during testing. The kernel package, or one of its alternatives (e.g., kernel-debug, kernel-rt), is selected through the blueprint. Previously, the standard kernel package was included in every image type definition, but this caused issues with ostree based images when the user selected an alternative kernel, since rpm-ostree breaks when there are multiple kernels installed. The issue cropped up again because of the separate depsolving. Selecting an alternative kernel in the blueprint caused two different kernels to be installed:

1. The blueprint-defined kernel
2. The standard kernel package which resulted from depsolving the main image package set.

This was solved by explicitly including the blueprint-selected kernel into the main image package list.

Comments

The reason I'm opening this issue (perhaps it would be better as a discussion) is because there's a tradeoff between the two solutions we have now in composer. I wanted to ask for opinions on which kind of situation and potential problem is preferable. Any other comments and opinions are also welcome.