On Fri, May 22, 2020 at 01:28:14PM +0200, Aleksandra Fedorova wrote:
> On Fri, May 22, 2020 at 9:29 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote:
> >
> > I'd like to point out that there is a difference in the enviroments between
> > these two approaches.
> >
> > While the manual procedure only installs a binary package (and its
> > dependencies), the OSCI procedure installs all binary packages produced by the
> > source package (and their depenencies).
>
> You are right here. Jenkins pipeline tries to install all packages
> from the koji build before running the test.
>
> And this approach has already hit us many times: there are packages
> where binary subpackages conflict with each other (as in curl), or
> where different tests require different subpackages to be installed.
> There is also a case for reverse dependency check, where we would like
> to run test suite from a package A to test the package B, where the
> koji build we are installing is different from what is expected by the
> test.
>
> In Fedora CI SIG we are discussing if we should just disable this
> functionality and make it mandatory to specify all packages explicitly
> in the tests.yml under "required_packages" tag, as in [1]
>
> The downside is:
> you would need to maintain list of required packages in the tests.yml
>
> We haven't brought this topic to a wider audience yet, but we should.
>
I don't have the statistics, but I believe that most of Fedora packages only
produce one binary package.
With that assumption, I would recommend defaulting to installing all of the
binary packages of the build. If there were a conflict, the installation would
fail, and a maintainer would fix the test by specifying the required_packages
explicitly. I.e. the required_packages tag should change a semantacs. Instead
of "the additional packages" it would mean "install these package only". In
other words the required_packages tag would default to the list of binary
packages produced by the build being tested.
That's my ideal approach from point of view of a package maintainer. Of course
I have no idea how difficult the implement is. Maybe it conflicts with the
currecnt OSCI design.
Regarding the case when a test of reverse dependcy fails because the build has
changed, I think it is a standard situation of breaking a compatibility and
the test should fail and the maintainer should decide what to do. E.g. to
move the update into a side tag and adjust the reverse dependency there.
> > In case of freecad, it does not matter, because the freecad component has only
> > one binary package. But in general it's not true.
> >
> > And here I'd like to ask Aleksandra whether the same applies to modules or
> > not. In general case, a module build produces two binary modules - a non-devel
> > module and a devel module. Does OSCI install components from both of them? And does
> > it install the components explicitly, or does it rather install a default
> > profile of the module ("dnf module install" command)?
>
> We don't have test for modules yet in Fedora CI.
The thing is that producing the devel modules is a matter of MBS
configuration and I feel that Fedora does not produce them in contrast to
CentOS.
> So I would say the question here is:
>
> how do you like it to work?
>
> We can do "dnf module install" but then the same issues would appear:
> if you need additional flexibility to test parts of the module, you
> would need to revert this default behavior somehow.
> Or we can do nothing and only provide environment with repositories
> with the updates. So that configuration of the environment is done in
> the test metadata.
>
The devel modules very often contain the pacakges that are only used for
building the non-devel module and building very often includes running unit
tests. That means that running tests for a module, will very probably need
packages from the devel module. Especially when the tests try to
reproduce the unit tests from the build time.
Since the non-devel module is supposed to work without the devel module, it
makes sense to run the tests by default without the devel module. To get to
the production environment as close as possible. On the other hand there will
be a need for having an acccess to the devel module packages.
I would not install the devel module by default, but provide a way of enabling
the devel module when needed.
Your question can also be understand as whether to preinstall all packages
produced by a module. Regardless of the mythical (in Fedora) devel modules.
On the one hand, modules are perceived as a cohesive group of packages. On the
other hand, I cannot preclude that somebody will create a module with curl
and the conflicting subpackages inside. I think I would resort to the same
approach as with the non-modular packages. Default to installing everything
with an option for overriding it to an explicit list.
-- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
