Le 14/06/2023 à 14:14, Petr Pisar a écrit :
V Wed, Jun 14, 2023 at 10:19:27AM +0200, Remi Collet napsal(a):
Your approach will move complexity back to packagers.
Yes. That's because the problem has a complexity and the complexity needs to live somewhere. With modularity it was in MBS and in modular filtering part of DNF.
For memory, all RPMs (even modular ones) are build with rpmbuild ;) mbs is only the "common" way, but not the "simple" way to build modular packages ;)
An extension of the stack will require the specific stream (build and run)
The extension can add build- and run-time dependenices on packages from that stream. However, that will effectively make the extension part of the stream. In that case a maintainer of the extension should including it into the stream. That, by a the proposed recommendations, would change an RPM name of the extension. I guess that Fedora would insist on this name change as Fedora's packaging guidelines now insist on nonmodular packages to only depend on nonmodular content.
Yes, make sense I was thinking of all C extensions (php-pecl-* and some other) which have a dependency on php(zend-abi) which is related to version, and possibly build options (nts, zts, debug...)
On the other hand, I can imagine that packages (especially top-level applications) which are not a logical part of any specific stream but depends on that nondefault stream, will retain its original name and simply users will have to switch the stream with "--allowerasing". It's the fragmentation of well-integrated Fedora Christopher (?) wrote in this thread. In his eyes there is no need for applications like that.
Yes, for now we use dependency on php(language) Usually we only require for minimal version (ex: php(language) >= 8.0) but sometime range dependency make sense (ex: roundcubemail which explicitly have a test for maximal version)
BTW, my preferred solution: keep building real modular packages ;) don't reinvent the wheel. In all cases, Fedora community won't like it.
Remi