Am 28.04.20 um 08:07 schrieb Simon Matter: >> 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). > > In other words, it does not have a solution for the problem mentioned above? > 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. -- Leon