Re: the sad state of installability tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux