On Mon, Jul 15, 2024 at 8:03 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. > This seems like overkill. Wouldn't the simplest valid installability test just be to test whether each subpackage *individually* could be installed? If we have 20 subpackages, just launch 20 separate minimal containers and see if `dnf install subpackageN` succeeds. Then it doesn't matter if there are conflicts; we know that at least installing that package directly will work. (Dependency resolution may pull in other subpackages of course, which is proving that it works properly.) -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
