Hi All, Trying to get my head round this modules thing with DNF. I think I get the idea. BUT, I have an PHP application that requires php-tidy. None of the module groups in the regular repositories offer php-tidy. The remi and cheese repositories do have it.
But if I configure those repositories and try to install php-tidy I get a module complaint like this
“Problem: package php-tidy-7.2.24-2.el8.x86_64 requires php-common(x86-64) = 7.2.24-2.el8, but none of the providers can be installed”
That version of php-common is in both appstream and the cheese repositories. ( Did I hear someone say .dll hell? )
How do I move forward with this without having a spiders web, or a dogs dinner, of a setup and a fundamentally broken system from an update point of view.
In principle the DNF modules is a nice idea, but the implementation has weak points. For example, packages for “same stream” from multiple repositories (e.g. Rocky and EPEL) is apparently not ok.
Traditional Yum repository has one or more versions of a package, say xxx-1.0, xxx-1.1, and xxx-2.0. You can install only one ‘xxx’ – the latest version.
The modules are just filters in the repository that exclude/include, well hide or keep available some packages. Say, streams ‘xxx/1’ and ‘xxx/2’. The first includes all xxx-1., and the second all xxx-2.. You can still install only one ‘xxx’, but now the user can opt to use only ‘xxx/1’ packages so that when repo maintainer releases ‘xxx-1.2’ and ‘xxx-2.1’, the user’s system can update from xxx-1.1 into xxx-1.2 (even though the repo already contains xxx-2.0 and xxx-2.1).
A repo can thus offer multiple “maintained branches”.
The Software Collections (SCL) in RHEL 6 and 7 had each “stream” with unique package names (and did also install “outside of PATH”, into /opt/).
Ken