On Mon, Jul 15, 2024 at 11:52:07AM +0000, Zbigniew Jędrzejewski-Szmek 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.
IMHO the package maintainer has already partitioned their sub-RPMs into sets by adding "Conflicts" lines where needed. ie each conflicting pair implicitly creates 2 sets. Can't the install tests be enhanced to follow deps info instead of asking maintainers to declare conflicts again in a different manner. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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
