On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote: > V Mon, Jul 15, 2024 at 08:45:53AM +0000, Zbigniew Jędrzejewski-Szmek > napsal(a): > > On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > > > I guess the test does not take RPM Conflicts into account. It's overly > > > optimistic when populating a system by installing all tested packages > > > together > > > instead of creating a new system for each test seperately. Or by adding > > > --allowerasing to "dnf install" invocations if the CI wants to reuse > > > the system. > > > > Yes and no. The test does not look at the package metadata at all, it just > > tries to install all the packages that were part of the update. > > In the case above, coreutils.srpm builds coreutils.rpm and > > coreutils-single.srpm, > > which have Conflicts on one another, and cannot be installed at the same > > time. > > > > The test which (I think) we really want is to install the combined set > > of packages from the update, so we exercise the situation that will occur > > on end-user systems, but exclude the packages from this set which are known > > to be not co-installable. > > > Maybe I conflate installability tests with rpmdeplint tests. We need both: > A test which checks that each package is separately installable. And a test > which tcgecks that wanted combinations of packages can be installed together. > > I cannot see how "exclude the packages from this set which are known > to be not co-installable" can be achieved automatically. Either the test will > examine package metadata for Conflicts to exclude the conflicting packages, or > someone will have to maintain the good set of combinanations.
Yes, I think those sets would need to be declared. The natural place for this declaration would be in dist-git of the package. For example for systemd: ci.ini: [InstallationGroups] group = *-standalone-* group = ~*-standalone-* For fedora-release: ci.ini: [InstallationGroups] group = fedora-release-common fedora-release*-basic group = fedora-release-common fedora-release*-budgie group = fedora-release-common fedora-release*-budgie-atomic group = fedora-release-common fedora-release*-cinnamon group = fedora-release-common fedora-release*-cloud group = fedora-release-common fedora-release*-compneuro group = fedora-release-common fedora-release*-container group = fedora-release-common fedora-release*-coreos group = fedora-release-common fedora-release*-designsuite group = fedora-release-common fedora-release*-i3 group = fedora-release-common fedora-release*-iot group = fedora-release-common fedora-release*-kde group = fedora-release-common fedora-release*-kinoite group = fedora-release-common fedora-release*-lxqt group = fedora-release-common fedora-release*-matecompiz group = fedora-release-common fedora-release*-mobility group = fedora-release-common fedora-release*-server group = fedora-release-common fedora-release*-silverblue group = fedora-release-common fedora-release*-snappy group = fedora-release-common fedora-release*-soas group = fedora-release-common fedora-release*-sway group = fedora-release-common fedora-release*-sway group = fedora-release-common fedora-release*-toolbx group = fedora-release-common fedora-release*-workstation group = fedora-release-common fedora-release*-xfce (I don't really care about the syntax. Just something that is easy to write and understand. And that the syntax is extensible to allow us to configure some other stuff in the future.) Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
