> 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. Thanks, Simon
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
> 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? Simon