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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
