Understanding Modularity

Home » CentOS » Understanding Modularity
CentOS 5 Comments

Hi,

I’ve read the Fedora modularity docs but am still missing the big picture somehow. Hope someone can clarify things for me.

What I’m most wondering: does modularity have any influence on the RPM
packages at all. I mean, is there anything inside a RPM package which says it belongs to a module or it has a special function in a module?

From what I understand the RPMs are just completely normal packages and only YUM/DNF knows from some metadata that an RPM belongs to a module. Is that corrent?

Thanks for any insights, Simon

5 thoughts on - Understanding Modularity

  • Well .. yes and no.

    Individual rpm packages have requirements for install .. so if a package is built against python38 , it will require python38 libraries. The individual RPMs though do not have knowledge specifically about Modules though, just the metadata.

  • Okay, so the rpm has it’s usual provides and requires, in this case a requirement for python38.

    Still, I don’t really understand how it can work for a simple example I
    have in mind. Let’s say there is this new, shiny Apache httpd version
    3.0.0 which requires this new and incompatible zlib version 2.0.0.

    How can this be built with modules? Dozen of RPMs depend on zlib version
    1.x.x, how is this situation handled with modules.

    Sorry, I just don’t really understand.

    Thanks, Simon

  • Am 27.04.20 um 17:31 schrieb Simon Matter via CentOS:

    IIRC: A module is just a set of RPM packages that can or must be installed together. Modules of the same “applications” can not be installed at the same time (PostgreSQL 10 or 12). Normally a core library would not be packaged as a module but technically possible. So, the new thing about “modules” is, that the package manager (dnf) can handle this bundles like it would be a single package (handled with the help of metadata).

  • Am 28.04.20 um 08:07 schrieb Simon Matter:

    Modules solves a different problem. Like, you can install your shiny httpd with the same name (httpd) like the default one and pinning it to this “shiny stream”. With both (default/shiny) applications (packages
    /modules) being in the same repo. If the shiny app needs a shiny zlib than that should be installed without producing conflicts (e.g. into
    /usr/local/) and the application should be linked against that lib.