libpkgmanifest is going to be used in container builds, operating on some base image. So in many cases, the dependency tree of an infile is not going to list every single package present on a system following a dnf manifest install---some packages will be already present in the base image. It follows that the user might want to specify in the infile a list of packages to remove from the base image.
Some change to the manifest schema would also be needed to list packages to remove.
https://github.com/konflux-ci/rpm-lockfile-prototype doesn't seem to have this, but it does have a similar section for reinstallPackages, which is a "List of rpms already provided in the base image, but which should be reinstalled".
If any "package to be removed" is not present in the system (and thus can't be removed), the manifest plugin should not error and should proceed silently, similar to if a package listed in the manifest is already installed.
That's my RFE, but in my ideal world, we wouldn't need something like this. It feels like a remnant of an older, imperative mode of operation. Ideally, the infile would always be a complete, pure description of a system and there would be some other mechanism for "layering" packages, e.g. composing multiple infiles with includes or supporting simple functions that can operate on groups+environments.
libpkgmanifest is going to be used in container builds, operating on some base image. So in many cases, the dependency tree of an infile is not going to list every single package present on a system following a
dnf manifest install---some packages will be already present in the base image. It follows that the user might want to specify in the infile a list of packages to remove from the base image.Some change to the manifest schema would also be needed to list packages to remove.
https://github.com/konflux-ci/rpm-lockfile-prototype doesn't seem to have this, but it does have a similar section for
reinstallPackages, which is a "List of rpms already provided in the base image, but which should be reinstalled".If any "package to be removed" is not present in the system (and thus can't be removed), the manifest plugin should not error and should proceed silently, similar to if a package listed in the manifest is already installed.
That's my RFE, but in my ideal world, we wouldn't need something like this. It feels like a remnant of an older, imperative mode of operation. Ideally, the infile would always be a complete, pure description of a system and there would be some other mechanism for "layering" packages, e.g. composing multiple infiles with
includes or supporting simple functions that can operate on groups+environments.