RPM Support

inter-modular dependency support will lead to a model change of Modulemd. A new field should be added. called `dependencies`

  dependencies:
  - buildrequires:
      httpd: [2.4]
      platform: [el8]
    requires:
      httpd: [2.4]
      nginx: [1.14]
      platform: [el8]

This is an example of how the deps could look. As per spec [0], there might be multiple instances of Modulemd.Dependencies() object, where each of them will describe different way of build with varying build time and runtime.

During recursive copy we do not really care if those modules are required during build time or runtime, I suggest to make a union between `buildrequires` and `requires` per instance of Modulemd.Dependencies() object.

I suggest the following data structure, where each dict will be a translated Modulemd.Dependencies() object.

dependencies: [
                            {module-name1:  [stream1, stream2, stream3],
                             module-name2: [stream1, stream2]
                            },
                            {module-name2: [stream3],
                            module-name3: [stream1, stream2]
                            }
                    ]

Note** there might me inclusive and exclusive lists of stream, where exclusive is marked with a minus sign. We need to preserve the minus for later conflicts solving.

Note** the `platform` module is synthesized at runtime by dnf, we can ignore it and not include in the deps info at all.

[0] https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L78

A new field should be added. called `dependencies`

Another option could be a list of flat dictionaries like:

[
   {
     "name": "foo",
     "streams": ["stable"],
     "type": "runtime"
  },
  {
    "name": "bar",
    "streams": ["master"],
    "type": "build"
  },
  }
    "name": "foo",
    "streams": ["stable"],
    "type": "build"
  }
]

This would allow to keep track of the build- vs. run-time dependencies. Plus they say "flat's better than nested".

milan wrote:

A new field should be added. called `dependencies`

Another option could be a list of flat dictionaries like:

[...]

This would allow to keep track of the build- vs. run-time dependencies. Plus they say "flat's better than nested".

Actually, it won't work. It would loose the "inner build environments links" which exist so that build environments can have mutually exclusive dependencies and I guess the solver would freak out. Thanks Ina for pointing this out!

ttereshc, now that i look at my comment which i wrote month ago, i cannot recall a reasonable explanation why we would care about buildrequires, unless we build modules which we do not.

+1 to drop buildrequires and include in the proposed structure just the requires.

we should also consider possibly using https://github.com/fedora-modularity/fus

ipanova@redhat.com wrote:

ttereshc, now that i look at my comment which i wrote month ago, i cannot recall a reasonable explanation why we would care about buildrequires, unless we build modules which we do not.

+1 to drop buildrequires and include in the proposed structure just the requires.

Thing is, the consumers of our published content might not be able to rebuild the modules themselves i.e we might create an installable but un-buildable repo. This isn't the case for for ursine content now, though we don't process SRPM deps recursively either.

Fus on the other hand considers the build-time dependencies.

To be clear for a quick reader, the relation with #4058 is weak.
#4058 requires only info of the first level module dependencies, if they are enabled on a consumer or not.

List of dependencies (requires only, not buildrequires) is added to the Modulemd model with this commit: https://github.com/pulp/pulp_rpm/commit/990f65a9bba8e3f9faf2f89165f2a88015dad1c1

ipanova@redhat.com wrote:

we should also consider possibly using https://github.com/fedora-modularity/fus

There are some trade-offs with Fus to consider:

• it is a command line tool that we'd have to integrate the way Pungi does
• we'd have to semi-publish (all) the source and destination repositories metadata
• this might have performance impact but we can afford experimenting with this idea

On the other hand, reimplementing some parts of both the Pungi and Fus tools seems like introducing code duplicity.
Still, the upside would be more control over how we resolve the dependencies.
There's an (undecided) Fus intgration e-mail discussion that can be queried for further information.