[CentOS] Understanding modularity

Tue Apr 28 15:31:42 UTC 2020
Leon Fauster <leonfauster at googlemail.com>

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.