Am 27.04.20 um 17:31 schrieb Simon Matter via CentOS: >> On 4/27/20 8:27 AM, Simon Matter via CentOS wrote: >>> 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? >>> >> >> 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. 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). -- Leon