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
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.
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
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
-
Johnny Hughes -
Leon Fauster -
Simon Matter